冴えない開発環境の育てかた

Transcript

1. 冴えない開発環境の育て方 Cloud Operator Days Tokyo 2021 (#CODT2021) あさぎ(@_athagi)

2. 今回お話すること 1. 元々どんな状態だったのか 2. この状態に至る経緯 3. どこから変えていったか 4. 変更が及ぼした結果 5.

   今後やっていくこと 2

3. 3 元々どんな状態だったのか

4. 運用しているソフトウエア • GitLab （ソースコード管理） • Jenkins （CI） • Harbor （Container

   registry） • Nexus repository （リポジトリ管理） • LDAP （ユーザ管理） • 複数の自作ツール 4

5. 元々の状態 • サーバ管理上の課題 ◦ OS は Ubuntu を利用していたが、更新がされておらず2020年の時点で EOLを迎えたバージョンを利用 ◦

   EC2 インスタンスを利用していたが、x4系（2015年- ）のインスタンスを利用 ◦ クラウドインスタンスと物理サーバが混在 ◦ 運用しているソフトウエアの定期的な更新はされておらず、塩漬け ◦ 定期的なバックアップはなし ◦ 複数のサーバがSPOFの状態になっている 5

6. 元々の状態 • 組織での課題 ◦ ドキュメント等はなく、サーバにあるものが全て ◦ コンソールから立ち上げているため再現性なし ◦ 管理の境界が曖昧 ◦

   社内の多くの人から利用されているにも関わらず、これらのサーバ等の運 用が片手間に行われており、関心が薄い ◦ CI パイプラインも属人化している 6

7. 元々の状態 役割間のインターフェースが決まっていないので、問題が発生した場 合や改善を行いたいときにオーバーヘッドが発生 7 Source Test Integration Delivery Deploy

8. 遠慮のかたまりを拾う状況...... 8 https://jsokuryou.jp/PDF/200409/sp-fail.pdf

9. 9 この状態に至る経緯

10. 経緯（成長期） • サーバの管理とサービスの提供をミッションとしたチームが存在 • SaaS 製品を利用するより、（額面上はメリットのある） 自前運用を選択 • チームに十分な人がいて、チューニングやメンテが行われていた •

    外部からの要求に答えるだけのパワーがある状態（コードに修正を入れたり、自 作ツールを導入） • 落ちない開発環境という外部からの期待 10 チーム 期待 要求 要求 要求

11. 経緯（成長期） • 開発インフラの構成がよくわかる＆管理者権限を持っているアクセスの 容易さからCIも受け持つように ◦ プロダクト開発組織からCIできる能力を外に出す ◦ 複数のプロダクトからの要求を取り入れた、なんでもできる最強のパイプラ インを作成 ◦

    最強のパイプラインにカスタムフックをマージできるよ！ 11 中央集権的な開発ワークフローが誕生

12. 経緯（成長期） • 機能別組織（縦割り組織）によって、特定分野で型にはめてCIの改善速度を高 めようとした • チームに十分なパワーがあり、周りの期待に答えつつ、環境をよりよくできてい た • 野心のあるチームは自前でツールの運用を始める •

    解決したい問題が現れたらとりあえず手を動かして解決していこう！ 12

13. 13 この状態が続けばよかったが......

14. 経緯（衰退期） • チームからナレッジが失われる ◦ チームから人は抜けるが補充はされず ◦ なぜその仕組みが入っているのかわからなくなってしまう ▪ 不要になった判断ができず、消せない •

    動けば良いというアドホックなFix によるその場しのぎ ◦ コードの管理者が不在 ◦ 困った人がその場しのぎで修正 ◦ デッドコードが多い自作スクリプト 14

15. 経緯（衰退期） • 運用上の問題 ◦ 外部から要求を持ってきた人は蒸発（ツールの導入だけされてメンテナ不 在の状態に） ◦ Day2（運用） 以前が評価されるため、Day2 に目が向かない

    （一見解決し ているように見えるが新たな問題を生み出している） ◦ 野心があり、自前で運用していたチームも運用しきれなくなる。一方で、利 用者も多くいたため、削除出来ずにチームに運用業務が回ってくる 15

16. 16 当時はベターな選択肢だった という前提で考えてみる

17. 当時を考古学してみる • メリット ◦ チームが成長サイクルにあって、予測可能なことが多い場合では、縦割り のメリットがある場合もある ◦ 特定の領域を深めつつ、各部署で起こる問題を横断的にまとめて解決して くれるため、プロダクト開発者は機能開発に集中できる ◦

    チームのパワーに余裕があるので、何かを作って（運用コストから目をそらしつつ） 問題を 解決することができる（とそれを行った本人の成果が上がる） 17

18. 当時を考古学してみる • デメリット ◦ 横断して開発環境を管理していたが、要求を受け付けるだけで、要求する 側に対して、あるべき状態を提示できていなかった ◦ Day1 まで手伝ってくれるが Day2

    について考えていなかったか、運用まで 手伝ってくれる人がいなかった ◦ 組織が存続するために成果や宣伝が必要で断ることができなかった 18

19. 19 何がたりなかったか

20. 何がたりなかったのか • 定期的に状態を見直して改善するということができなかった • 役割としてタスクがアサインできていなかった（雰囲気でやっていた） • チームと外界の線引きが明確でなかった • チームの責務が明確でなかったので、トレードオフを考えられなかった 20

21. 21 どこから変えていったか

22. “ 過負荷な状態からの回復 複雑性の排除 22

23. 複雑さの計測 • トレーニング時間 ◦ ドキュメントが貧弱だったり欠けていると参画者 が戦力になるのに時間がかかる • 説明の時間 ◦ 全体像を説明するのにかかる時間

    • 管理の多様性 • デプロイされている構成の多様性 • 年代 ◦ 何もしないとシステムは腐る ◦ 利用者の実装に依存するようになる(ハイラムの法則 ) 23

24. レガシーシステムから離れる過程 • 回避 ◦ 問題に正面から取り組まない ◦ 実質的に技術的な負債を受け入れる • カプセル化/拡張 ◦

    レガシーシステムをラップ ◦ 徐々に置き換える準備のための一時的な手段 • 置き換え/リファクタリング ◦ 外部とコミュニケーション・ドキュメンテーションが必要で高コスト ◦ 現状の振舞いから逸脱しないようにする必要がある • 退役/監護義務 ◦ 移行しなかったチームにレガシーシステムを渡す 24

25. どこから変えていったか • 現状の把握（予想した経緯と現状の差分） • 業務の継続性の回復（ドキュメント化、IaC化、属人性の排除） • 認知負荷の削減 ◦ 今は利用されていない（価値が出ていない）設定やコードの排除 ◦

    ソフトウエアの更新 • デファクト・スタンダードに寄せる • セルフサービスでパイプラインを作成できるようにした ◦ 自分たちもパイプラインを容易に作成できるようになった • 「葬り」を行う ◦ 問題の量を減らす ◦ 新しく何かを作ることはしない 25

26. トイルの削減と自動化 • トイルを自動化により削減する場合 メリットがコストを上回るようにする • コスト削減のメリットと自動化の労力 が釣り合う場合もキャリアやモチ ベーションなど、見えないメリットが ある 26

    https://xkcd.com/1319/

27. 変えようとしたときのハードル • この時間帯は止めないでくださいといった要求 ◦ 受け入れられる要求は受け入れ、無理なものは跳ね返す ◦ （SLOベースで対応できればスマートだった） • 「実は使われているかもしれないので消せないのでは」という耳打ち ◦

    明らかに使っている部分は対応を行う ◦ 使われているか不明な部分については実際に消して確かめてみる。問題 が起こった際にロールバックできるようにしておく 27

28. 変えようとしたときのハードル • 数年の更新差分を含むので deprecated が abolished になっていて壊れる ◦ 中央集権的な状態であったのが逆に幸いして一括で対応できた（数年更新をサボっ たつけが回ってきた）

    • 周りのチームへの説明 ◦ 将来的にフローを変更するにあたって味方を増やすために早め・多めの連 絡を取るようにして透明性を確保した 28

29. 29 何がかわったか

30. 元々の状態 30 Source Test Integration Delivery Deploy

31. 何が変わったか（外部） • 新規/比較的小規模なチームは自然と自分たちの管理下でCICDパイプラインを 管理するようになった • 他チームにCICDパイプラインを委ねている複数のチームを跨ぐ大規模なプロダ クトは事実上の担当者がいても移行しなかった • バージョンを一気に更新した際は大変だったが、それ以降の定期的な更新に対 しては肯定的な反応を得られた

    • リファレンスを参照する際に、過去バージョンをあさらず、最新のリファレンスを 見て対応できるようになった 31

32. 何が変わったか（内部） • IaC 化されたことで、変更点の差分が確認できるようになった • 更新の差分が小さくなり、更新のハードルが低くなった • CICDパイプラインの整備までのハードルが低くなった • なぜこの状態になっているかが明確になったことで、葬るタイミングや改善のディ

    スカッションが行いやすくなった • 運用の範囲が明確になったことで、外部からの圧力に対して話し合いが行いや すくなった 32

33. 33 今後やっていくこと

34. 今後やっていくこと • 会社の価値につながらない部分は外部のサービスを利用する ◦ お金を出す層への説明、実際の利用者が移行してくれる仕掛け • 世間から見たデファクトスタンダードなやり方を利用する（その上で会社に合うよ うに工夫を行う） ◦ キャッチアップ時間やキャリア上でメリット

    • 外部チームと X-as-a-Service でコミュニケーションできるようにする ◦ 不要な複雑性を定型業務に変換して削減 ◦ 必要な複雑性を集約する • SREのプラクティスを実践 34

35. Collabolation から X-as-a-Service へ • Collabolation モードでチーム間の役割・責任は共有する。境界は曖昧になる一 方で迅速な問題解決と組織の学習が手に入る • XaaS

    モードで別チームから提供されるサービスを利用する。責任や境界が明確 な場合、利用者は迅速にサービスの利用を開始できる。一方でプロダクトマネジ メントが不可欠 35 Skelton, Matthew; Pais, Manuel. Team Topologies

36. Collabolation から X-as-a-Service へ 36 https://jsokuryou.jp/PDF/200409/sp-fail.pdf 理想的な 組織

37. Collabolation から X-as-a-Service へ [若い組織（成長途上の組織）] → [ 理想的な組織] → [年老いた組織/腐った組織]

    • 継続的に振り返りを行いながら、自分たちのチームは価値を提供できているか を確認していく • チームが持っているタスクのうち、定型（自動化できる）タスクや葬ることが可能 なタスクの評価を継続的に行う 37 Skelton, Matthew; Pais, Manuel. Team Topologies ？

38. 今後やっていくこと 38 Source Test Integration Delivery Deploy • 利用者が単独で開発サイクルを回していけるようにする •

    CICDを管理できる能力を利用者側に移行（するために役割を定義）

39. 39 fine