DevOpsアンチパターンとは?

2013年1月9日

開発担当者と運用担当者が一緒に協力し、迅速に開発、リリース、フィードバックを回すことでビジネスを成功に導いていくという「DevOps」。もともとはFlickrやFacebookなどコンシューマ向けのオンラインサービス企業から登場した考え方ですが、いまではIBMなど企業向けのソフトウェア開発でもDevOpsを用いるベンダが登場してきています。

Devops Anti-Patterns — Agile Web Development & Operations

その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

開発者がプロセス全体を支配したところで、また彼らが運用を学び直すことになる。どちらかが支配するのではない。

協力するカルチャーを作るというのは、頭では理解できても具体的なアクションとしてどう進んでいけばいいのか、迷うこともあると思います。そうしたときに、このアンチパターンは役に立つのではないでしょうか。それにしても、ここにあげられたアンチパターンはどの組織でも大なり小なり抱えていることではありますね。

2012 Velocity London: DevOps Patterns Distilled from realgenekim

関連記事

あわせて読みたい

DevOps




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本


<!- script for simple analytics events -->