DevOpsアンチパターンとは?
開発担当者と運用担当者が一緒に協力し、迅速に開発、リリース、フィードバックを回すことでビジネスを成功に導いていくという「DevOps」。もともとはFlickrやFacebookなどコンシューマ向けのオンラインサービス企業から登場した考え方ですが、いまではIBMなど企業向けのソフトウェア開発でもDevOpsを用いるベンダが登場してきています。
そのDevOpsで重要なのが、開発も運用も誰もが協力し合うというカルチャーを作り上げていくこと。Webサイト Agile Web Development&Operationsの記事「DevOps Anti-Patterns」では、これをやるとDevOpsが失敗するというアンチパターンを3つ挙げています。
3つのDevOpsアンチパターン
アンチパターン1:コミットが“完了”/Committed is “Done”
メンバー全員がタスクを終了させるとはどういうことかを理解するために、アジャイルのプラクティスとして“完了”を定義するのはよいことですが、ここに落とし穴がある、とこの記事は指摘します。
For a developer, this is thinking “committed is Done”; for a sysadmin “My script is running and I can understand it”. Sad to say it folks, but this isn’t Devops!
Every developer must think of the end user.
デベロッパーにとって、“コミットが完了”と考えるでしょう。システム管理者なら“スクリプトが実行され、それが理解できている”ことだといえます。でもみんなちょと待って。これはDevOpsなんだよ!
(DevOpsでは)あらゆるデベロッパーはエンドユーザーのことを考えなくてはならないんだ。
つまり、QAが通ったコードをコミットしたら完了とか、管理スクリプトがちゃんと動いたら完了と考えてはいけないと。DevOpsではちゃんと利用者がそのコードで実装された機能が利用できるようになって、はじめて完了だということです。
Good developers want to ensure that the new features are not only coded, but tested and ultimately released to their users. Only then the task is really Done.
よいデベロッパーは、新しい機能のコードを書いたらそれだけではなく、テストをし、最終的にはユーザーへリリースされたことを確認しようとします。そのときこそが、本当にタスクが完了したということなのです。
アンチパターン2:僕の担当はここまで/My Responsibility Ends Here
開発も運用も全員が協力し合うというカルチャーを作り上げるには、仕事の割り振りを超えて、全員が責任を共有し合う考えが重要だと。
No matter if there’s a code or operations problem, everyone should feel responsible and help find a fix.
コードの問題だろうと運用の問題だろうと関係なく、だれもが責任を感じ、問題発見に力を貸すべきだ。
もちろん、仕事のなすり合いといったことは御法度でしょう。
アンチパターン3:彼らがやるべきだ/They Should
If you start seeing “us vs them” emerging in your organization, fight it. Make sure people understand everyone’s contribution to the overall success of your organization and provide more interaction between these islands of “us” to improve communication.
もしも“俺たちvsあいつら”といったことがあなたの組織で起ころうとしているなら、それと戦いなさい。だれもが自分たちの組織全体の成功に貢献し、そしてコミュニケーションの向上によって“俺たち”といった縄張りを解いていくのです。
ここに挙げられた3つのアンチパターンは、誰もが共通の責任と目標を持って協力し合うために何をすべきで、何をすべきでないかを具体的に説明してくれています。DevOpsを実現しようという組織だけでなく、あらゆる組織の改善に役立つ助言かもしれません。
記事ではこうまとめています。
Only a feeling of belonging together will foster collaboration and lead to a Devops culture.
自分たちは同じ組織に属しているのだと感じることが、コラボレーションを育て、DevOpsのカルチャーへと導いていくのだ。
4つのDevOpsアンチパターン
もう1つ、別のDevOpsアンチパターンも紹介しましょう。こちらは2012 Velocity Lodonのイベントで行われた「DevOps Patterns Distilled」というセッションのスライドから、アンチパターンとして挙げられている項目を4つ。
1)Config Management = DevOps
構成管理ツールを入れればDevOpsができると思ってはいけない。協力し合うカルチャーを作り続けていくことが重要なのだとのこと。
2)Guerrilla DevOps
プロセスの一部だけをDevOpsっぽくしたからといってそれほど効果は期待できない。プロセス全体を統合すると。
3)Start a separate DevOps Group
DevOpsグループなんてのを作ったところで、また新しいサイロを1つ作るだけだ。全体で取り組むべき。
4)Silo X takes Over
開発者がプロセス全体を支配したところで、また彼らが運用を学び直すことになる。どちらかが支配するのではない。
協力するカルチャーを作るというのは、頭では理解できても具体的なアクションとしてどう進んでいけばいいのか、迷うこともあると思います。そうしたときに、このアンチパターンは役に立つのではないでしょうか。それにしても、ここにあげられたアンチパターンはどの組織でも大なり小なり抱えていることではありますね。
関連記事
あわせて読みたい
jQueryの利用率はWebサイト全体の55%。使わないサイトの方が少数との調査結果。W3Techs
≪前の記事
2012年のクリスマスイブ、Amazonクラウドから降ってきたシステム障害。原因はオペレーションミス