多義化するOpsのミッションについて
今年度から運用の担当になったんですけど、最近消化不良を起こしつつあります。立場としては言われたことだけやるオペレーターという形じゃなくて、いわゆるインフラエンジニアっぽい感じだけど構築はやりませんよって感じです。日々のオペレーションや障害対応をやりつつ、一方でDevOpsの整備とかに注力している感じ。でも自分のミッションはそこまで社内で明確化されているわけではなくて、どうもそのあたりに消化不良の原因がある。
Opsの担うミッションの変化
そもそもにしてDevとOpsの境界ってどこなんだろうという定義はわりと曖昧な気もしますが、おそらくは「リリース」が境なんでしょう。基本的にはリリースまでを担当するのが「開発」で、リリース後のシステム稼働の面倒を見るのが運用、保守というイメージでいるのだけど、「運用」が担うミッションって最近かなり広がっているような気がするんですよね。
一番難易度の低い運用といえば、いわゆる手順書に沿った業務しかやらないオペレーター作業になるわけですが、そういう運用と開発の業務内容、職掌をガッツリと分けた状態って最近は主流ではなくて、いわゆるDevOps的に開発フェーズからデプロイされて本番運用へと移っていく過程がシームレスになっていくのが常識化しつつある。あと運用というのも、システムを単に放っておいてトラブルが起きたら対応、という受動的なものではなくて、能動的にメトリクスやログを解析して、SREのようにソースコードにまで手を入れて、安定運用のための方策を講じていくスタンスが生まれつつあります。
少し前だと、いわゆるインフラエンジニアが運用も担っているようなケースは特にWeb系だと多く見られていたし、Infrastructure as Codeの黎明期には「インフラエンジニアもコードを書けるべき」ということが盛んに言われていましたが、もはや時代は「運用の中でソフトウェアのコードを編集する」というところまで来ていて、だいぶ時代が移り変わったように見える。
Ops先鋭化へのジレンマ
もともとインフラエンジニアが運用を担っていたパターンにおいて、SREのような業務を来月からやりましょうってのはまず無理だと思っています。スキルの畑があまりに違うので。やるのであれば人員の配置換えをするか、インフラエンジニアにかなりの学習コストを払わせることが必要になる。ので、ちょっとSREの話は先鋭的すぎるとして置いておくとしても、いわゆる「インフラエンジニアもコードを書けるべき」は求められる場面が多くなってきたように思う。
そもそも旧来の運用業務にしたところで、一切コードを書けない人間が担えたとは思えないんですよね。まぁ「手順書運用」は一切スキル不要なので別として、何か処理を自動化して効率化しましょうとなればスクリプトぐらいは書ける必要があるし、OSSの監視ツールを使いましょうとなれば、ソースを読む機会ぐらいはある。ただ、実際に運用業務に携わっていて思うのは、それを出来る人間というのは現実として限られてもいる。インフラエンジニアが運用を兼ねるようなケースであれば尚更です。
堅牢性を求めて保守的なシステム運用をしようとすれば、運用は「決められたことだけをやる」「引き継いだことだけをやる」という方向にシフトしがちなわけで、そうなってくるとコードを読み書きするスキルが必要とされる場面は当然ながら減ります。その場合のスキルはインフラ周りに重点が置かれて、コードの修正はソフトウェアエンジニアに任せることになる。手作業のオペレーションが煩雑であるならば、ソフトウェアエンジニアへ自動化を依頼するかもしれない。
どちらが良い、どちらが悪いという話ではなく、スキルと職掌による問題なんだろうと思っています。同じシステムを運用していても、コーディングスキルがあるエンジニアであれば自ら自動化をしよう、ソースコードを確認してみようという手の動かし方になるし、コードに携わるのは自分の職務ではないと認識していて、スキルも持ち合わせていないエンジニアであれば、誰かに任せればいいという思考になる。
（運用も担っていた）インフラエンジニアの役割が変わってきた、というよりは、スキルやマインド、スタンスの面で、コーディングスキルのあるOpsエンジニアが別の方向へ進み始めたというように思えます（繰り返しになりますが、どちらが良し悪しということではなく、決められた手順だけを実施させることで運用のコストを下げる、というのも一つの考え方だとは思っています）。
圧倒的技術力の必要性
ところで、DevOpsはさておき「システム運用」全体を網羅したような本ってあんまりないです。最近は少し出るようになっていて『インフラエンジニアの教科書』などはそれに近いですが、（サーバー）構築の話も入ってくるので、純粋な運用というとオライリーの『ウェブオペレーション』が一番ハマっているかなと。
オライリージャパン
売り上げランキング: 371,961
Amazonに在庫ないっぽいので絶版かもしれないですがいい本でした。監視の考え方から継続的デプロイ、障害対応に関してまで載ってる。技術書というよりはエッセイっぽいですが、運用ってどんなことやるんだというのがわかる本。
圧倒的な技術力が求められる職種だ /「ウェブオペレーション」を読んだ - kakakakakku blog
レビューを上げているブログを貼りましたが、このタイトルにもある通り、この本を読むと「圧倒的な技術力が求められるわ……」と呆然とします。2011年の本なので、SREのような先鋭化したスタイルに言及があるわけではないですけど、そもそも障害への対応にしたって、原因を切り分けるにはコンピュータアーキテクチャーのレイヤーから、OS、ミドルウェア、ソフトウェア、ネットワークと様々な視点を考慮する必要があるわけです。原因追求をせず、手順書通りに再起動や再実行をして「とりあえず」復旧したからOKとするのも運用と言えば運用ですけど、システムの安定性を保つためにどちらが望まれるかとなれば、大きな違いが出てくる。また運用や障害対応は組織で行うのが基本なので、うまいこと人員が動いて有機的に連携していくには、時に心理学や社会学の知識も役に立ったりします。
思うのは、Opsという領域が二分されてきているんじゃないかということです。運用を標準化して、決まったことをやることでコストを抑えた方式と、SREへ辿り着くような、漸進的にシステム改善を図りながら安定稼働を目指す方式。なんとなく、前者のエンジニアが後者へ移り変わっていくようなイメージを持っていましたが、そもそもスタンスとして前者を是とする人と、後者を是とする人の2種類に分かれてきているように思う。B to BのサービスでSLAを握っているのなら、多少システムリソースの使用率が逼迫していても、SLAの範疇で運用されていれば問題がないわけだし、そこでパフォーマンスチューニングをしてもお金が取れるわけではないので得策ではない。となればSREは必要ないかもしれない。といった具合に、スタンスの違いでミッションも変わってくる。
自分の場合は後者のスタンスを欲しています。SREのような高いスキルは現状持ちあわせていないけど、システムの安定した稼働、高効率な稼働に寄与して、エンジニアの対応コストを抑えていくというのをミッションにしたいなという思いが強くなってきている。が、それも会社が目指すOpsの方向性と噛み合っていないと無意味です。「運用」という言葉で括れる範囲は極めて広く、多義的になってきている昨今で、先に示したように「これ1冊！」という本を読めばOKというものでもないです。なので、まずはリリース後のシステムをどうしようか、というOpsのミッションをブレずに定義することが求められているのかなというのが最近の実感でした。
ちなみに自分が思うOpsの職掌としては、クックパッドさんのインフラエンジニアの職掌範囲がとてもしっくりきていますね。