[DevSecOps] #1 ビジネスを加速する文化的処方箋

DevSecOPSとは

1.概念

「development」(開発)と「operations」(運用)、その言葉が明確に分けられ、役割の違いを表しているように。組織内の構造が分かれている事を伴って、必要のない摩擦や作業(組織の大小に関係なく、分かれていることが原因で責任の所在が不明瞭になる事)を生んでいるパターンがしばしば見受けられる。その分断≒細胞壁を破り、ビジネスの方向性によって柔軟に形を変えられる有機体を目指すために、この言葉が生まれたと理解している。また、このような名前付を行う事によって文化となり、ToDoを明確化し、エンジニアリングの価値を実現するスピードを早める考え方であると捉えている。この活動を通して、

・チーム内の透明性が増し、チーム内に信頼が生まれる。

・実際にダメージの大きいミスをする前に、それを防ぐ方法をチームメンバに伝えられる。

・新しい問題の解決に使える時間が増え、より本質的な活動に時間を多く割ける。

・そもそも、新しいプロダクトを設計するにあたって長期的に発生するであろう技術的な負債を回避できる。

上記のような満足があるという認識。

一般的に知られているのは、何か作業を自動化するであったりとか、新しいツールを導入するということが表に出てくることが多いが実際の根本的な課題は、分断されていた状態であったためお互いに理解しあう為のスタンスを持つまでに少しリハビリが必要な事だったりするんじゃないかと思ってる。そしてそのような構造が時間と共に大きくなっていけばいくほど変えづらい物になるので本当に初期に取り組むべき活動だと考えている。

2.具体例

実際に上記の文化がない状態だったとしたらどんな現状が起こるのかを書いてみる

• 運用面 :
  • 緊急で入る運用業務に時間が取られ定時過ぎてから「自分の案件」に着手する...
  • 肥大化したリソースの管理を手動で行うため、運用ミスで重大な毀損の事故を起こす
  • secondary繋げ忘れて参照できない問い合わせが来る
  • primaryが容量が100%でDBがdown
  • slow queryによって、その他のプロセスがつまる
  • 多数のサーバーの脆弱性対応で一日中工数が奪われる
  • そもそもセキュリティ領域の作業などが属人化しているので開発側が分からない
• 開発面 :
  • 複数の案件が同時に走るため、マージ後のテストのし忘れによる事故発生
  • 密結合なサービスに機能追加したので、全てに影響が出てしまいテストケース増
  • 新規案件の影響範囲や工数を適切に見積もることができる人材がいない
  • UnitTestがなくて手動による確認を行う。結果考慮漏れがあり事故

その結果どうなるのか

• 企画が提案する案件は、非常に工数が意識されたその場しのぎの案件が走る
• そもそも既存のソースコードが汚いので。。という妥協
• 運用が属人化して、新規参入者が活躍しずらい組織に
• 問い合わせやバグなどの発見が非常に困難

上記の事例をあげるだけでも枚挙に暇がない。

3.上記の文化を実現するために

実際にアクションを起こした内容について[DevSecOps]のタグと共に具体的に行ってきた事の詳細を発信しようと思う。