DevOpsを考える
開発から運用へ
今まではアプリ開発のメンバとしてずっとやってきたのだけど
いろいろとあってインフラ開発・運用のリーダとして仕事をすることになった。
上司からはDevOpsを求められている。
運用の現場
運用に入って正直驚いた。
チケットは１行「作業完了」といって解決にしているし、
リポジトリにコミットせずに、なぜか部の共有ディレクトリにファイルをあげている。
そこには「XXXX_201407XX.txt」なんて対比されているファイルもある。
と思えば、リポジトリにはチケットの作業ログがあげられている。
特にレビューも作業結果も確認せずにクローズされているチケット。
ただ、運用メンバに加わることで見えてくることもあった。
- 「人のせい」にしないで「プロセスのせい」にして、ちゃんとした振り返りを作業後に行っている。Good
- 複数のプロジェクトの運用を行っているため、コンテキストスイッチが多くなかなかつらい。
- 実工数分しか発注されていないため、そもそも運用改善をする時間が取れない。
- 「何のために」をちゃんと教わっていなそう
現場を見て、DevOpsに悩む
個人的な理想 DevOps。
運用と開発をがっちゃんこした一つのチームにして運用も開発もみんなができるようになって。
なんてことが本当にできるのか？
やはり「運用」としての人材としてきてもらっている人にいきなりコード書けは敷居が高すぎるし
運用メンバには負担でしかないのではないか？
DevOpsと言いはじめたとき、運用メンバも開発やるのか・・・勉強しなきゃって不安があるという噂を聞いた。
開発メンバは開発効率が下がるだーなんだーいって、運用をやりたくないことしか伝わらない。
そもそもプロセスが全く違うしどうやって一つのチームとしてまとめるんだろう？
数週間頭が痛いのが続いた。
正直会社にも行きたくねーってなった。（あ、これは普段通りかもw）
上司、開発リーダからの助言
運用にコードを書けとは言わない。もっと他にもやることがあるだろう。
DevOpsだからといって一つのチームでということではない。
いろいろなDevOpsの体系があるんだから焦らずに、中長期的に見据えていこう。
DevOpsについて学ぶ
固まっていた思考がだいぶほぐれた気がした。
というかそもそもDevOpsについて勉強していなかった。
勝手にそういうもんだと思い込んでいた。
DevOpsはキーワードは知っていたけど、勉強していなかったのでほんとうに「にわか」ダッタと思う。
いまでも「にわか」だけど前よりはましになっただろう。
今日、その辺りの資料をいろいろと読んでみた。
そもそも開発は変更を加えたいと運用は安定かどうさせたいというミッションの違いがあることから対立がおきている。
そこでビジネスゴールという共通の目標をたてて、同じ方向を向き、クリアするためにどうするか。
なんかアジャイルを勉強していたときに聞いた話だった。
結局は、
素早く、お客さんに黄金体験（ゴールドエクスペリエンス）を提供する
あくまでこれが大前提であることがわかった気がする。
アジャイルと同じでDevOpsに形はない。チームにあった自分たちのやり方を考えるんだ。
自分はよく手段を目的にしてしまうことがあるので、「何のために」を先に考えることが必要。
さて、今後どうしていくか。
