DevOpsと言う言葉がGartnerやIT業界の有名人から注目を集め、製品化までの時間が短縮され、よりよい品質とさらなる利益が求められる中、ローマで開催されたDevOps Dayでは、Damon Edwards氏がDevOpsの文化を広め、単に自動化だけに注目しないようにする方法について議論した。
Damon氏は、実際にDevOpsの考え方を持つ会社の共通の柱を明らかにした。
- システム思考: システムのエンド・ツー・エンドの考え方。ビジネスのアイデアから技術的な実装までを含む。開発と運用の機能を細分化する。
- フローへの注目: 開発ライフサイクルを通して成果物とワークフローがどれだけ速く流れるかを確かめながら、効率的にビジネスのアイデアを使えるサービスに変換する
- フィードバックのループを拡大: 変化の結果に対して何が起きるかについてすぐにフィードバックを得ることで、システムについて素早く学ぶ。
- 継続的な実験と学習: 今までにあげたポイントの仕上げは、継続的改善の態度とフィードバッグループをうまく利用することだ。
Damon氏は、上記の4つの柱を達成するために、成功したDevOpsの組織で使われた日々の仕事のやり方を、プラクティスや初めの一歩として例を示した。
- 「Done」という言葉を追放した。サービスは決して終わることはなく、常に動いていて、継続的にケアしなければならない。
- 運用上の要求を第一に扱い、初期の段階で影響を見えるようにする。運用上の要求は、機能的要求と同じパイプラインを通っている。
- 作業のフローを可視化して、誰でも全体で何が起きているのかが分かり、ボトルネックが自然に明らかになる。
- システム全体を理解し、無駄を目立たせるために、協力してバリューストリームを決める。
- 情報フローを成果物フローに変えて、漠然とした情報の受け渡しを減らし、人々の間で必要とされるお互いへの影響を明らかにする。
- 関連するデータを意味のある測定基準にまとめ、別々の組織にいるステークホルダが状況を把握できるようにする。
- 変化を測定基準に照らし合わせ、チャートを用いて表すことで、変化に対する気付きを与える。
- 気付いたことをオフィスの壁に貼りだし、誰もがシステム全体の一部だと感じるようにする。
- コントロールを分散し、成果物のプロデューサーとメンテナンスする人の責任を揃える。例えば、開発する人はコードの使用可能時間に責任を持ち、運用する人はプラットフォームの利用時間に責任を持つ。
- 内部的に少人数で会議を実施し、何が行われていて、何ができあがるのかを全員で理解し、誰でも変化を起こす力があると感じられるようにする。
- 必ず開発の確認を行い、運用の助けを借りて、開発者によって提供される各サービスを確実なものにすることで、壁に書かれた問題を避ける。
- サルを檻から出してサービスに準拠した完全に信頼できるものを提供する。
- 問題が起きたら、変更や追加の作業のためにパイプラインの流れを止め、ボトルネックの元を見つけ出すことに集中し、そのボトルネックを解決する。
- 顧客に対してすべてを見せる。物事が間違った方向に行っているときはもちろん、うまくいっていて、顧客が満足しているときも気を付けること。
- チームや通常のワークフローの外で関係を築き上げて楽しもう。例えば、「アドミンは誰」ゲームや社内の適当な人とランチに行くなど。
現在、Damon氏はDevOps Cookbookの他の優れたリーダたちと共に働き、ここで取り上げたようなトピックを扱っている。DevOps Days in Romeのこのプレゼンテーションや他のプレゼンテーションはこちらで視聴できる。