ブログ

えっとDevOpsを始めたいのかな？おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。

古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。

パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避けるために、DevOpsコミュニティからもちょっと助けを得てこのリストを作成したんだ。

1. DevOpsはプロセスである

必ずしもそうじゃない。DevOpsは哲学であり、考え方なんだ。DevOpsはプロセスとツールによってサポートされる。

Gene Kimによれば、DevOpsとは3つの核となる原則によって支えられている。

• 1つめはシステム全体の成果、すなわちバリューストリームが重要視されているということ
• 2つめは短い増幅されたフィードバック・ループ
• 3つめは継続的な学習と理解を育てるような文化を作ること

詳しくは以下のリンク先を確認してほしい

http://itrevolution.com/pdf/Top11ThingsToKnowAboutDevOps.pdf

2. Agile = DevOpsである？

こういう質問をするってことは、たぶん何らかのアジャイルプロセスを使っているんだろうね。それはそれで良いことだね。DevOpsにあった開発プロセスを既に導入しているってことだから。でもアジャイル＝DevOpsを導入しているってことにはならない。

DevOpsは、IT運用から顧客が価値を実現できる本番環境へのデプロイの作業までの継続的なフローを協力してサポートする、といったことをアジャイルに実現するものなんだ。

3. あなたの組織のOpsやDevやその他のチームをDevOpsという名前に変える

• CIO：「この一年でDevOpsを取り入れたいんだ」
• マネージャー：「もう完了してます。今朝部署の名前を変えました。もう2つもDevOpsチームがあるんですよ！」

いやーすごいですねー（棒。そこらじゅうに「DevOps」エンジニアがいることでしょうねー。まぁ運が良ければ、彼らはランチの時くらいは隣同士で座ってるかもしれないね。

4. 独立したDevOpsグループを作って始める

さぁやってみな。できたかい？よくできた！君はDevOpsを実行したんだ。ただ実際に君がやったのは別のサイロを作っただけだ。統合しなきゃいけない別のチームができたってことだ。そして別のチームにも壊さなきゃいけない壁がある。また立ち戻って名前を変えて新しいDevOpsチームを作って…ひどいことになるねぇ。

DevOpsは開発者やオペレーションの人をチェリーピックして新しいサイロを作ることじゃないんだ。

包含して組み込まないといけない。

開発チームを壊してOpsチームとかその他のチームに組み込むんだ。

チーム間の障壁やガードをぶっ壊して、共通のゴールと責任をもったひとつのチームに作る必要があるんだ。

以下の資料を参照するといい。

http://www.slideshare.net/realgenekim/2012-velocity-london-devops-patterns-distilled

5. 敵対的な乗っ取り

DevOpsって単語は「Dev」から始まってるということは、開発（Development）が主導権を取る。だって開発が先に来てるでしょ？何か問題でも？

• Devのマネージャー：「えー、僕らDevOpsをやってるんだ。なのでチームのメンバーは本番環境のシステムを学習しなきゃいけないんだ」
• Opsのマネージャー：「あー、オッケー。で誰がコードを開発するのさ？」

DevOpsって単語は気の利いた言葉で、混成語だ。2つの単語を組み合わせて新しい単語になっていて新しい意味を持っているんだ。Developmentって単語でOperationという単語を置き換えるってことじゃない。なので、なんでそういうやり方をしようとしちゃうのかな？

DevOpsは両者がお互いの主要なスキルを認識することを求めているんだ。お互いが協力するために必要なことを共有するんだ。改善するために学習しなきゃいけないことを学ぼう。これは再教育するって意味ではないし、クロススキル化するって意味でもない。もちろんそれで良いことなんだけどね。これは改善のためにフィードバックと可視性を提供するってことなんだ。

http://www.slideshare.net/realgenekim/2012-velocity-london-devops-patterns-distilled

6. DevOpsはバズワードである

君がDevOpsをバズワードだと思うってことは、たぶんクラウドも間違った使い方をしているんだろうね。。。DevOpsは単語っていうのはいいよね？実際のところDevOpsっていうのは開発(Development)とIT運用(Operation)の混成語なんだ。DevOpsは単なるかっこいいバズワード以上のものだ。これはマインドの状態を表しているんだ。その価値を受け入れて、他の人がその価値を受け入れるのを助け、自分自身を改善しつづけ、うまくいくように他人の改善も助けなきゃいけない。BS(訳注：これなんでしょうね…)を捨てて協力しはじめれば、みんなが新しい「DevOps」って言葉が実際にクールだと思うようにできるんじゃないかな。

http://www.slideshare.net/realgenekim/2012-velocity-london-devops-patterns-distilled

7. DevOpsを銀の弾丸として売り込む

DevOpsはおまじないだ。君は開発チームと運用チームが一緒になるようにするだろう。彼らはペヨーテを吸って鶏を捧げる。ひとたび君の組織で革命を起こせば、今までより速くソフトウェアを出荷できるようになるはずだ。設定は自己管理されるし、デプロイツールもよく理解できるようになる。開発チームと運用チームはお互いが調和するようになるだろう。

ということで、DevOpsは大変だ。多くの場合文化の変化が必要になるんだ！これがもっとも大変なことの1つだ。熟練した開発や運用チームに対して、世界をひっくりかえそうとしているんだ。一朝一夕でやろうとしちゃダメだ。そんなことしたら失敗するよ。

8. DevOpsとは開発者が本番環境を管理することである

違う。違うといったら違うんだ！僕はとても頭に来ているんで、君はこの記事を読まなきゃダメだよ！

9. DevOpsとは開発駆動のリリースマネジメントである

2つのことをはっきりさせておこう。

1. DevOpsは開発駆動じゃない
2. DevOpsは運用駆動でもない

もし君が開発駆動の環境がほしいならそれもいいだろう。やってみたらいいよ。ただそれをDevOpsと呼んだらダメだ。DevOpsじゃないから。

たとえば以下の記事を読んでみるといいよ。

http://www.computerweekly.com/cgi-bin/mt-search.cgi?IncludeBlogs=113&tag=release%20management&limit=20

「DevOpsでは、プログラマーはプログラマーだ」

→よーしその調子だ！

「同じように、DevOpsでは運用スタッフは運用スタッフだ」

→そろそろ料理の時間ですかね…

「伝統的に、ソフトウェアを本番環境にリリースするのはオペレーションと開発チームのどちらかにある」

→ちょっと待て…

「運用チームはアジリティや対応時間を犠牲にして、ダウンタイムを最小化して安定性を保証するような環境のデプロイ戦略を作る」

→そうだね。軌道に戻ってきた。バーーーーン！

「開発駆動のリリースマネジメント」

→なんじゃそりゃ？

「開発駆動のリリースマネジメントは別の方向に進んでいて、どうやったらできる限り頻繁に簡単にデプロイを実行できるかを見ている。でもこういうデプロイが必ずしも本番環境で用意されているわけじゃない。プロセスの観点でみると、継続的デリバリーでは2つの点を要求している。1つはプロセスそれ自体はしっかり固まっていなければならないこと。すなわち伝統的なIT組織が導入していたプロセスと同じようにしっかり固まっていなければならないということを意味する」

→ちがいます。ちがう。ちがうとき。ちがうけど。ちがう。

開発駆動で何かすることはプロセスだ。DevOpsじゃない。運用チームを自動化されたデプロイプロセスで置き換えることはナンセンスだ。良い子のみんなはこんなことしちゃいけないよ。

[訳注]別にデプロイ自動化が悪いと言っているわけではないので注意。開発者主導で勝手にプロセスを決めていくこと自体の問題を説いている

10. 我々は特殊なので、DevOpsできない

そうですねー（棒。でもDevOpsを導入できないほど特殊じゃないよ。君は凄腕の開発者で、光よりも速くコーディングして、お客さんを歓喜で涙させるようなコードをリリースしているんだと思うよ。違う？おっけー。君は地球上でもっとも優れた運用の人なんだね！チャック・ノリス(訳注：アメリカの空手家、俳優)が運用エンジニアなら望む通りにやればいい。でも君や君の組織でDevOpsの導入を許してくれないような特殊な事情はないはずだ。やってみよー！

Opscode社のJesse Robbinsが始めるにあたって役にたつアドバイスをいくつか用意しているので見てみるといい。

• 小さく始める−信頼をつくる
• チャンピョンを作る
• 自信をつける
• 成功を祝う
• 状況をふまえる

http://www.slideshare.net/jesserobbins/cloud-expo-jesserobbinsopscode20130129b

https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/adoption_antipattern_we_re_special?lang=en

11. 我々には適任者がいないのでDevOpsできない

じゃーなんでそういう人たちを採用したの？そう、みんなすごい人たちだよ！

もし君がそう思うわないなら、君は自分自身をしっかりと見つめなおして、君のチームの隠された本当の能力を見つけるようにしよう。

最近だれかが僕に言ったんだけど、彼らは間違った開発者や運用者がいるからDevOpsできないんだそうな。ってことは彼らはコードを書けない開発者を雇っているってことかな？僕も、僕の組織では間違った開発者とかコードを書けない人がいて、彼らは人事とかマーケティングをやっている、って思ったこともあったよ。

この協力関係はチーム間同士という範囲を超えて、組織全体に広がっていくはずだ。

君のところに間違った人なんかいやしない。間違った思考プロセスなだけだ。話をそらしちゃダメだ！

12. よくないことが起こった時のコラボレーション

おっけー。君はしくじった。それで？みんなでそれをやってみた。でも君は運用の人に彼らが何にもしらないことを夜中の2時に直してほしいと思ったわけだ。彼らは運用エンジニアであって、マイケル・クレイトンみたいな揉み消し屋じゃないんだ。デプロイのあいだ中開発の人と運用の人が何か問題が起こるまで待機しているなんてことはうまくいかない。

この問題に対しては遅すぎるかもしれないけど、次回の役にもたたない

開発チームと運用チームでお互いに会話させよう（午前2時の罵り合いかもしれないけど）。でも少なくとも君がそうしなくても話していると思うよ。

対話を促進しよう。起こってしまったことをふりかえり、どう直すか話そう。

もし君がこういう状況に遭遇してしまったら、チームの間で会話し続けるようにさせることだ。

開発チームと運用チームのコミュニケーションチャンネルを早く作ろう。それが希望だ。

http://cdn.dzone.com/sites/all/files/refcardz/rc145-010d-continuousdelivery_0.pdf