Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
冴えない開発環境の育てかた
Search
athagi
July 14, 2021
Technology
0
57
冴えない開発環境の育てかた
#CODT2021 (7/14~) でお話してきました。
https://event.cloudopsdays.com/codt2021/talks/10
athagi
July 14, 2021
Tweet
Share
More Decks by athagi
See All by athagi
社内でAWS GameDayを開催しよう
athagi
1
260
petなEC2をまとめて監視してみた
athagi
1
140
既存の仕組みを棄てる技術
athagi
0
680
GitLab-CI でPrivate Registry を利用する話
athagi
0
1.1k
Kubernetes がない世界の CloudNative ジャーニー
athagi
0
310
ゆるキャンはじめました。
athagi
0
1.5k
Windows Server にAnsibleを使ってみた話
athagi
2
1.9k
Other Decks in Technology
See All in Technology
ACRiルーム最新情報とAMD GPUサーバーのご紹介
anjn
0
150
開発と事業を繋ぐ!SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~
leveragestech
0
620
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
220
20240717_イケコパ代表Copilot_in_Teams会社でこう使ってます
ponponmikankan
2
430
ペパボのオブザーバビリティ研修2024 説明資料
kesompochy
0
1.1k
AOAI Dev Day - Opening Session
yoshidashingo
2
430
DevIO2024_レガシー運用からの脱却 -クラウド活用の実践事例とベストプラクティス-
jun2882
0
210
Scaling Technical Excellence at 104: Evolution in AWS and Developer Empowerment
scotthsieh825
1
150
AWSサービスメニュー開発をしていてAWSを好きだ!と感じた瞬間
toru_kubota
0
130
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
120
Docker互換のセキュアなコンテナ実行環境「Podman」超入門
devops_vtj
6
3.2k
Classmethod Odyssey 登壇資料
yamahiro
0
390
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
291
20k
How to Ace a Technical Interview
jacobian
274
23k
Side Projects
sachag
451
42k
Git: the NoSQL Database
bkeepers
PRO
423
64k
GraphQLとの向き合い方2022年版
quramy
36
13k
The Power of CSS Pseudo Elements
geoffreycrofte
64
5.2k
5 minutes of I Can Smell Your CMS
philhawksworth
200
19k
Typedesign – Prime Four
hannesfritz
37
2.2k
Being A Developer After 40
akosma
72
580k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
What's new in Ruby 2.0
geeforr
338
31k
Making Projects Easy
brettharned
111
5.7k
Transcript
冴えない開発環境の育て方 Cloud Operator Days Tokyo 2021 (#CODT2021) あさぎ(@_athagi)
今回お話すること 1. 元々どんな状態だったのか 2. この状態に至る経緯 3. どこから変えていったか 4. 変更が及ぼした結果 5.
今後やっていくこと 2
3 元々どんな状態だったのか
運用しているソフトウエア • GitLab (ソースコード管理) • Jenkins (CI) • Harbor (Container
registry) • Nexus repository (リポジトリ管理) • LDAP (ユーザ管理) • 複数の自作ツール 4
元々の状態 • サーバ管理上の課題 ◦ OS は Ubuntu を利用していたが、更新がされておらず2020年の時点で EOLを迎えたバージョンを利用 ◦
EC2 インスタンスを利用していたが、x4系(2015年- )のインスタンスを利用 ◦ クラウドインスタンスと物理サーバが混在 ◦ 運用しているソフトウエアの定期的な更新はされておらず、塩漬け ◦ 定期的なバックアップはなし ◦ 複数のサーバがSPOFの状態になっている 5
元々の状態 • 組織での課題 ◦ ドキュメント等はなく、サーバにあるものが全て ◦ コンソールから立ち上げているため再現性なし ◦ 管理の境界が曖昧 ◦
社内の多くの人から利用されているにも関わらず、これらのサーバ等の運 用が片手間に行われており、関心が薄い ◦ CI パイプラインも属人化している 6
元々の状態 役割間のインターフェースが決まっていないので、問題が発生した場 合や改善を行いたいときにオーバーヘッドが発生 7 Source Test Integration Delivery Deploy
遠慮のかたまりを拾う状況...... 8 https://jsokuryou.jp/PDF/200409/sp-fail.pdf
9 この状態に至る経緯
経緯(成長期) • サーバの管理とサービスの提供をミッションとしたチームが存在 • SaaS 製品を利用するより、(額面上はメリットのある) 自前運用を選択 • チームに十分な人がいて、チューニングやメンテが行われていた •
外部からの要求に答えるだけのパワーがある状態(コードに修正を入れたり、自 作ツールを導入) • 落ちない開発環境という外部からの期待 10 チーム 期待 要求 要求 要求
経緯(成長期) • 開発インフラの構成がよくわかる&管理者権限を持っているアクセスの 容易さからCIも受け持つように ◦ プロダクト開発組織からCIできる能力を外に出す ◦ 複数のプロダクトからの要求を取り入れた、なんでもできる最強のパイプラ インを作成 ◦
最強のパイプラインにカスタムフックをマージできるよ! 11 中央集権的な開発ワークフローが誕生
経緯(成長期) • 機能別組織(縦割り組織)によって、特定分野で型にはめてCIの改善速度を高 めようとした • チームに十分なパワーがあり、周りの期待に答えつつ、環境をよりよくできてい た • 野心のあるチームは自前でツールの運用を始める •
解決したい問題が現れたらとりあえず手を動かして解決していこう! 12
13 この状態が続けばよかったが......
経緯(衰退期) • チームからナレッジが失われる ◦ チームから人は抜けるが補充はされず ◦ なぜその仕組みが入っているのかわからなくなってしまう ▪ 不要になった判断ができず、消せない •
動けば良いというアドホックなFix によるその場しのぎ ◦ コードの管理者が不在 ◦ 困った人がその場しのぎで修正 ◦ デッドコードが多い自作スクリプト 14
経緯(衰退期) • 運用上の問題 ◦ 外部から要求を持ってきた人は蒸発(ツールの導入だけされてメンテナ不 在の状態に) ◦ Day2(運用) 以前が評価されるため、Day2 に目が向かない
(一見解決し ているように見えるが新たな問題を生み出している) ◦ 野心があり、自前で運用していたチームも運用しきれなくなる。一方で、利 用者も多くいたため、削除出来ずにチームに運用業務が回ってくる 15
16 当時はベターな選択肢だった という前提で考えてみる
当時を考古学してみる • メリット ◦ チームが成長サイクルにあって、予測可能なことが多い場合では、縦割り のメリットがある場合もある ◦ 特定の領域を深めつつ、各部署で起こる問題を横断的にまとめて解決して くれるため、プロダクト開発者は機能開発に集中できる ◦
チームのパワーに余裕があるので、何かを作って(運用コストから目をそらしつつ) 問題を 解決することができる(とそれを行った本人の成果が上がる) 17
当時を考古学してみる • デメリット ◦ 横断して開発環境を管理していたが、要求を受け付けるだけで、要求する 側に対して、あるべき状態を提示できていなかった ◦ Day1 まで手伝ってくれるが Day2
について考えていなかったか、運用まで 手伝ってくれる人がいなかった ◦ 組織が存続するために成果や宣伝が必要で断ることができなかった 18
19 何がたりなかったか
何がたりなかったのか • 定期的に状態を見直して改善するということができなかった • 役割としてタスクがアサインできていなかった(雰囲気でやっていた) • チームと外界の線引きが明確でなかった • チームの責務が明確でなかったので、トレードオフを考えられなかった 20
21 どこから変えていったか
“ 過負荷な状態からの回復 複雑性の排除 22
複雑さの計測 • トレーニング時間 ◦ ドキュメントが貧弱だったり欠けていると参画者 が戦力になるのに時間がかかる • 説明の時間 ◦ 全体像を説明するのにかかる時間
• 管理の多様性 • デプロイされている構成の多様性 • 年代 ◦ 何もしないとシステムは腐る ◦ 利用者の実装に依存するようになる(ハイラムの法則 ) 23
レガシーシステムから離れる過程 • 回避 ◦ 問題に正面から取り組まない ◦ 実質的に技術的な負債を受け入れる • カプセル化/拡張 ◦
レガシーシステムをラップ ◦ 徐々に置き換える準備のための一時的な手段 • 置き換え/リファクタリング ◦ 外部とコミュニケーション・ドキュメンテーションが必要で高コスト ◦ 現状の振舞いから逸脱しないようにする必要がある • 退役/監護義務 ◦ 移行しなかったチームにレガシーシステムを渡す 24
どこから変えていったか • 現状の把握(予想した経緯と現状の差分) • 業務の継続性の回復(ドキュメント化、IaC化、属人性の排除) • 認知負荷の削減 ◦ 今は利用されていない(価値が出ていない)設定やコードの排除 ◦
ソフトウエアの更新 • デファクト・スタンダードに寄せる • セルフサービスでパイプラインを作成できるようにした ◦ 自分たちもパイプラインを容易に作成できるようになった • 「葬り」を行う ◦ 問題の量を減らす ◦ 新しく何かを作ることはしない 25
トイルの削減と自動化 • トイルを自動化により削減する場合 メリットがコストを上回るようにする • コスト削減のメリットと自動化の労力 が釣り合う場合もキャリアやモチ ベーションなど、見えないメリットが ある 26
https://xkcd.com/1319/
変えようとしたときのハードル • この時間帯は止めないでくださいといった要求 ◦ 受け入れられる要求は受け入れ、無理なものは跳ね返す ◦ (SLOベースで対応できればスマートだった) • 「実は使われているかもしれないので消せないのでは」という耳打ち ◦
明らかに使っている部分は対応を行う ◦ 使われているか不明な部分については実際に消して確かめてみる。問題 が起こった際にロールバックできるようにしておく 27
変えようとしたときのハードル • 数年の更新差分を含むので deprecated が abolished になっていて壊れる ◦ 中央集権的な状態であったのが逆に幸いして一括で対応できた(数年更新をサボっ たつけが回ってきた)
• 周りのチームへの説明 ◦ 将来的にフローを変更するにあたって味方を増やすために早め・多めの連 絡を取るようにして透明性を確保した 28
29 何がかわったか
元々の状態 30 Source Test Integration Delivery Deploy
何が変わったか(外部) • 新規/比較的小規模なチームは自然と自分たちの管理下でCICDパイプラインを 管理するようになった • 他チームにCICDパイプラインを委ねている複数のチームを跨ぐ大規模なプロダ クトは事実上の担当者がいても移行しなかった • バージョンを一気に更新した際は大変だったが、それ以降の定期的な更新に対 しては肯定的な反応を得られた
• リファレンスを参照する際に、過去バージョンをあさらず、最新のリファレンスを 見て対応できるようになった 31
何が変わったか(内部) • IaC 化されたことで、変更点の差分が確認できるようになった • 更新の差分が小さくなり、更新のハードルが低くなった • CICDパイプラインの整備までのハードルが低くなった • なぜこの状態になっているかが明確になったことで、葬るタイミングや改善のディ
スカッションが行いやすくなった • 運用の範囲が明確になったことで、外部からの圧力に対して話し合いが行いや すくなった 32
33 今後やっていくこと
今後やっていくこと • 会社の価値につながらない部分は外部のサービスを利用する ◦ お金を出す層への説明、実際の利用者が移行してくれる仕掛け • 世間から見たデファクトスタンダードなやり方を利用する(その上で会社に合うよ うに工夫を行う) ◦ キャッチアップ時間やキャリア上でメリット
• 外部チームと X-as-a-Service でコミュニケーションできるようにする ◦ 不要な複雑性を定型業務に変換して削減 ◦ 必要な複雑性を集約する • SREのプラクティスを実践 34
Collabolation から X-as-a-Service へ • Collabolation モードでチーム間の役割・責任は共有する。境界は曖昧になる一 方で迅速な問題解決と組織の学習が手に入る • XaaS
モードで別チームから提供されるサービスを利用する。責任や境界が明確 な場合、利用者は迅速にサービスの利用を開始できる。一方でプロダクトマネジ メントが不可欠 35 Skelton, Matthew; Pais, Manuel. Team Topologies
Collabolation から X-as-a-Service へ 36 https://jsokuryou.jp/PDF/200409/sp-fail.pdf 理想的な 組織
Collabolation から X-as-a-Service へ [若い組織(成長途上の組織)] → [ 理想的な組織] → [年老いた組織/腐った組織]
• 継続的に振り返りを行いながら、自分たちのチームは価値を提供できているか を確認していく • チームが持っているタスクのうち、定型(自動化できる)タスクや葬ることが可能 なタスクの評価を継続的に行う 37 Skelton, Matthew; Pais, Manuel. Team Topologies ?
今後やっていくこと 38 Source Test Integration Delivery Deploy • 利用者が単独で開発サイクルを回していけるようにする •
CICDを管理できる能力を利用者側に移行(するために役割を定義)
39 fine