DevOpsアンチパターン
「DevOpsアンチパターン」という記事を見つけたのでメモ。
アンチパターンをもっと作れたら面白いだろうと思う。
【元ネタ】
DevOpsアンチパターンとは? - Publickey
【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に関するアンチパターンを読むと、開発チームと運用チームをいかに一体化して作業していくべきか、に関する内容が多い。
アジャイル開発の知識がある人ならば、アジャイルなプラクティスととても似ていることに気づくだろう。
だからこそ、とても面白い。
そしてこの分野は今なお、いろんなアイデアを試しながらノウハウや失敗例を収集し、整理して、普遍的概念を抽出しようと試みている時期なのだろう。
その意味ではとてもホットな分野であり、今後も注目していく。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
「Agile」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
「パターン言語」カテゴリの記事
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2(2020.12.31)
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1(2020.12.30)
- なぜユーザーストーリーによる要件定義にピンとこなかったのか(2020.12.29)
- AWSクラウドデザインパターンの感想~RDP(Redmine Design Pattarn)の構想(2020.03.01)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
コメント