運用チームとSREチームの共存
SREは運用をソフトウェアエンジニアにやらせた結果できたものなので、対象が従来の運用チームと重なる。
運用チームをSREチームにするというパターンが多そうだが、そのチームメンバー、プログラム書けるのか？
SREのメンバーはGoogleですら採用に苦労しているらしく、ソフトウェアエンジニアとしての基準をだいたい満たしている人を教育しているようだ(SRE本参照)。
つまり、プログラムを書けない人はSREのメンバーにはなれない。業務時間の50%以上を開発に充てることを目標にしているのだから、当然といえば当然だ。
「プログラム書けないのであればSREではないからクビ」というわけにはいかないので、従来の運用チームとSREチームの二本立てというところに落ち着くことになる。
運用の理想と現実
- 作業はドキュメント化されており、タイムリーに更新されていて実システムとの違いがない。
- 作業はチケットで管理されており、作業ログもチケットに添付されている。
- 障害はちゃんと原因調査が行われ、必要に応じて開発部門にエスカレーションされている。
教科書通りの運用だ。多少いびつになるが、定型的な作業はSREがコード化、自動化していくことで、運用対象の規模が大きくなっていっても、やっていけるだろう。もちろん、長期的には運用チームの縮小、解散を行うことも可能だろう。
実際はどうか？
- ドキュメントは更新されていない。あるいは、そもそも作業がドキュメント化されておらず、個人のノウハウに頼りきっている。
- 何をやったのか記録が残っていない。
- 動くようになったらOK,OK。動いているんだから、原因なんて追求しない。そんな時間、そもそもない。
SREとか言う前に、「ちゃんと運用するとはどういうことか」を教育する必要があるだろう。それすら、「動いているんだからOK」で無視されそうだ。
運用チームは低く見られる
SIerだと、システムを作って納品するまでが主流とみなされており、出来上がったシステムの運用保守といったお守りは低く見られている。いや、見られている会社がある。
プログラムを書く人が多数派となっている集団においては、書けない少数派が肩身の狭い思いをしてもしょうがない。
SREは運用に光を当てたバズワードであるものの、結局、プログラムが書けない人の立場を改善するものではない。
さらに、最近はプログラムが書けることを前提とした手法(テストの自動化、Infrastructure as Codeなど)が広まってきており、書けない人の立場はますます厳しくなっていくであろう。
共存はできるが一時的なもの
同じことをやるのであれば、自動化コード化で人手のかからない手法が有利であり、SREチームが優勢だろう。だが、今動いているシステムの中身を知っているのは運用チームの面々であり、彼らが持っているノウハウを引き継がない限り、SREが活躍するのは難しい。
とはいえ、いつかは退職するのが会社人。引き継ぐ先がSREとしてやれる人であれば、意外と早く変われるのではないか。