devopsをする理由
- 間違えてももとに戻すことができる
- 成功するためにやるのではなく、効率よく失敗できるようにするためにする。
ウォーターフォールモデルの弊害
ウォーターフォール・モデルの弊害は、後戻りができない ことだ。
ゲームで例えましょう。例えば、１ステージを攻略をしている際に２ステージで必要なアイテムがあったとしましょう。しかし、あなたは１ステージを攻略最中にそのアイテムを忘れてしまった。そうすると、２ステージでは攻略ができずにゲームそのものが詰みになってしまいます。
通常の場合ですと、１ステージに戻ることはできます。１ステージに戻ってアイテムを入手してそのまま２ステージで使えば問題なくクリアすることができます。
しかし、ウォーターフォール・モデルではそうは行きません。ウォーターフォール・モデルは「要求→要件→開発→運用」で開発がされていて、開発から要件、運用から開発、と後戻りは許されていません。つまり、どこかのタイミングである間違えを見つけても前のステージに戻ることはできません。
要件から要求くらいなら1ステージ戻るだけですのまだ傷は浅いです。しかし運用の場合は戻るとしたら要求まで戻らないとういけなくなります。つまり、一からすべてを辿ってやり直さないと問題が解決しません。
こうなると、そもそも運用上で発見した開発の問題は容易に直すことはできない。どのステージでも後戻りができないから詰んでいるが分かっているのに、ゲームを続けるのと同じ行為をしています。
そのようなゲームがあったら、普通はそのゲームをやめて別のゲームに移ってしまいます。ですが、現実世界ではそのようなことは簡単にはできない。そうしたら今まで払ったお金が帰ってこなくなる。発注者からしたらたまったものではない。
また、オートメーション化をして効率よくしたくても要件でそのようなことは盛り込まれていないからソフトを使うことができない。
ゲームなら、強化アイテムを使えば楽に勝てるのにゲーム自身が縛りプレイでレベルをあげられないのと同じ。クソゲー以外の何者でもない。
更に、書くステージで完全分業制を敷いているので、お互いの仕事を手伝うことも口出しすることもできない。つまり、拙いソフトを運用者に渡したら開発者を恨み、拙い要件を開発者に渡したら要件を作った人を恨み、拙い要求を要件を作る人に渡したら要求した人を恨む、という殺意の連鎖が出来上がってしまう。
良く言えば「お互いが仕事を全うすればいい絆が生まれる」
悪く言えば「お前がへましたら首を差し出せ。介錯してやる」
というお互いずっ友並に信頼もへったくれもないような上っ面どころじゃないお互い仮面をかぶって喉元に刃物を突き刺している状態になります。
devopsとは？
では、そのような弊害を迎えて何をするのか？解決すべき問題は以下のとおりだ
- 後戻りしてもいい
- カイゼンをするのに過度な許可を必要としない。
- お互いの仕事を理解して自分の仕事をまっとうする
ゲームのように言い換えれば
- 前のステージに戻ってもいい
- レベルアップができる
- お互いのジョブを理解をして自分のジョブを全うする益をもたらすであろう
ゴーストオブツシマの百合の言葉「力は我らの周りにあり。」
確かにdevopsの本を読むと小難しいことを言っていますが、ゲームに置き換えて考えれば難しいことは言ってはいません。
今週の調べたことはこれまで。
です。別に特別なことは言ってはいません。ゲームで当たり前のことを口に出しただけです。
まずdevopsですが、簡単にいうと開発者がアプリを開発したら自動でサーバーないしマシンに対して自動コンパイルができて、運用した結果をすぐに開発に反映することができる。
開発者は容易にマシンにコンパルができるように自動化がされているのでその分運用者の手間が減る。その分運用者は運用の仕事を思う存分できる。作ったアプリがヒットしてサーバーの負荷が上がったら対処を考える時間ができる。今までのように起こったら筋肉で解決みたいな筋肉殺法をする必要がなくなる。
筋肉殺法がなくなることによって、運用コスト自体が低くなり運用者の継承も以前よりも楽になる。更にカイゼンが制度上容易になれば昨日よりもよりよりものができる。
更に、カイゼンが進めば自ずとお互いの仕事を理解が以前よりも進む。コンパイルの自動化は運用者が考えてくれた構成図通りに機械がコンパイルをしてくれるように作らないとうまく動作をしてくれない。その過程で開発者は運用者の理解が進むことが考えられる。
失敗することも大切
そして、失敗をしてももとに戻すことができる。例えば、自動化をするにあたって設計をミスしてしまったとします。通常の場合は自動化に際して自動化の手順をコードで表しています。
コードで表しています。すると、gitの力を使ってコードを前の状態に戻すことも可能です。それ以外にも、ansibleならばインストールの作業をコード化していてどのデバイスでも、OSなどの指定をしていればインストール作業はコマンド1つでできるので人為的なミスも減らせます。そうすることで失敗をしても元に戻して、また最初からやり直すこともできます。
devopsは成功をするためにやるのではなく、失敗ができるようにするためにやるのです。ゲームでいうと、ストックという概念を持ち込んでいる感じです。
プレイヤーが失敗をすることを許容しないゲームは大抵はプレイヤーからそっぽを向かれてしまいます。要するに、成功を当たり前にするのではなく、失敗することを当たり前にして、その失敗から方法を編み出すことができる。これが一番大切なのです。
ゲームも同じで大抵は死んで強くなります。何回もゲームオーバーしますがその都度対策を立てたり、敵のパターンを探ったり、弱点を見つけようとします。
失敗はある程度肯定するものであって、敵視するようなものではない。depopsは自動化によって失敗しやすい環境作りを目指すことができます。
別に特別なことなどはしない。
以上の点からもそれほどスゴイ技術を使っているわけではない。以前から存在していた方法を実践しているのに過ぎない。
おそらくゲームで培われた技術は現実世界で姿を変えて有益をもたらすであろう
ゴーストオブツシマの百合の言葉「力は我らの周りにあり。」
確かにdevopsの本を読むと小難しいことを言っていますが、ゲームに置き換えて考えれば難しいことは言ってはいません。
今週の調べたことはこれまで。益をもたらすであろう
ゴーストオブツシマの百合の言葉「力は我らの周りにあり。」
確かにdevopsの本を読むと小難しいことを言っていますが、ゲームに置き換えて考えれば難しいことは言ってはいません。
今週の調べたことはこれまで。