DevOpsアンチパターン

「DevOpsアンチパターン」という記事を見つけたのでメモ。
アンチパターンをもっと作れたら面白いだろうと思う。

【元ネタ】
DevOpsアンチパターンとは？ － Publickey

AWS-CloudDesignPattern

【1】クラウドが出現して以来、Webインフラもプログラマブルになってきた。
そのおかげで、開発と運用が以前のようにチームとして分離するのではなく、一体化して作業していく方向へ進化している。
以前はWebの基盤構築作業は、設計書を事前に入念に作り、その設計書に従ってサーバーやメモリ、HDD、ルータなどのハードウェアを揃えて構築するというWF型開発が主流だった。
でも、仮想化技術やクラウドのおかげで、構築後にスケーラビリティを上げることもできるし、事前に入念な計画を作らずとも試行錯誤しながら基盤構築できる時代になってきた背景がある。

クラウドに関するデザインパターンは、下記の記事が有名だろう。
AWSに特化したパターンだが、そのノウハウは従来の基盤構築でも十分通用すると思う。

「クラウドデザインパターン」をAmazonが公開。システム冗長化、突発的トラフィック対応、動的コンテンツ処理など45種類 － Publickey

「クラウドアーキテクティング原則」。クラウドデザインパターンの背後にある、システム設計の原則とは － Publickey

僕も以前に記事を書いた。

クラウドデザインパターン～インフラ方式設計のベストプラクティス集: プログラマの思索

【2】上記の記事では、以下のアンチパターンが紹介されている。
クラウドでWebサイトを公開している経験があれば、こんな失敗例があったな、とか思うのではないだろうか。

(引用開始)
1)アンチパターン1：コミットが“完了”／Committed is “Done”

デベロッパーにとって、“コミットが完了”と考えるでしょう。システム管理者なら“スクリプトが実行され、それが理解できている”ことだといえます。でもみんなちょと待って。これはDevOpsなんだよ！
（DevOpsでは）あらゆるデベロッパーはエンドユーザーのことを考えなくてはならないんだ。

よいデベロッパーは、新しい機能のコードを書いたらそれだけではなく、テストをし、最終的にはユーザーへリリースされたことを確認しようとします。そのときこそが、本当にタスクが完了したということなのです。

2)アンチパターン2：僕の担当はここまで／My Responsibility Ends Here

コードの問題だろうと運用の問題だろうと関係なく、だれもが責任を感じ、問題発見に力を貸すべきだ。

3)アンチパターン3：彼らがやるべきだ／They Should

もしも“俺たちvsあいつら”といったことがあなたの組織で起ころうとしているなら、それと戦いなさい。だれもが自分たちの組織全体の成功に貢献し、そしてコミュニケーションの向上によって“俺たち”といった縄張りを解いていくのです。
自分たちは同じ組織に属しているのだと感じることが、コラボレーションを育て、DevOpsのカルチャーへと導いていくのだ。
(引用終了)

(引用開始)
1）Config Management = DevOps
構成管理ツールを入れればDevOpsができると思ってはいけない。協力し合うカルチャーを作り続けていくことが重要なのだとのこと。

2）Guerrilla DevOps
プロセスの一部だけをDevOpsっぽくしたからといってそれほど効果は期待できない。プロセス全体を統合すると。

3）Start a separate DevOps Group
DevOpsグループなんてのを作ったところで、また新しいサイロを1つ作るだけだ。全体で取り組むべき。

4）Silo X takes Over
開発者がプロセス全体を支配したところで、また彼らが運用を学び直すことになる。どちらかが支配するのではない。
(引用終了)

DevOpsに関するアンチパターンを読むと、開発チームと運用チームをいかに一体化して作業していくべきか、に関する内容が多い。
アジャイル開発の知識がある人ならば、アジャイルなプラクティスととても似ていることに気づくだろう。
だからこそ、とても面白い。

そしてこの分野は今なお、いろんなアイデアを試しながらノウハウや失敗例を収集し、整理して、普遍的概念を抽出しようと試みている時期なのだろう。
その意味ではとてもホットな分野であり、今後も注目していく。