アドベントカレンダー2日目です。前回はSREの「はじめに」を読みました。
今回は、SREの１章「イントロダクション」について、読み進めていこうと思います。
本の内容的には、ほぼ歴史の話になります。個人的に歴史は好きですし、重要だと思っているので、それだけでまとめることには価値があると思いますが、読んでもらえるのか不安な回です。なので、すこし物語を付けました。
サービス管理の歴史：シスアド編
歴史的に、企業は複雑なコンピューティングシステムを動作させるためにシステム管理者を雇用してきました。
シスアドとも呼ばれるこのシステム管理者のアプローチでは、既存のソフトウェアコンポーネントを組み合わせてデプロイし、それらを共に動作させてサービスを作り出します。シスアドはサービスを運用し、イベントが発生したり、イベントに応じてアップデートが必要になるたびに対処します。1
まずは、既存のシスアドの説明が書かれています。この説明には、特に疑問はありません。自分のイメージとも合っています。
シスアドによるサービス管理のモデルには、以下のようなのメリットがあると書かれています。
企業がサービスの運用やスタッフ割り当てを決めるにあたって、このアプローチは比較的実施しやすい方法であり、業界では馴染みのあるパラタイムであることから、学んだり真似たりできる例が多くあります。また、関連する能力を持つ人員も広く集めることができます。こうして構築されたシステムの稼働を支援してくれる既存のツールやソフトウェアコンポーネント（出来合いのものかどうかにかかわらず）は、熟練していないシスアドのチームでも車輪の再発名やゼロからのシステム設計をせずに済むのです。1
こう言われると、シスアドのモデルは悪くないように思えます。企業にもシスアドにもやりやすい環境ができているように感じます。しかし、このモデルにもデメリットがあり、それは直接的なコストと間接的なコストに大別できるそうです。
直接的なコストは明らかです。変更管理やイベント処理を手作業に頼るチームがサービスを稼働させる場合、サービスそのものの成長やトラフィックの増大に伴いコストがかさんでしまいます。これは、そのシステムの運用における負荷の増大に伴って、チームも大きくしていかざるをえないためです。1
これは、かなりぞっとする話です。仮にシステムの不具合が起きたとき、１つの環境だけなら、いいですが、２つなら？３つなら？（１００個なら？）恐竜は巨大化したことによる維持費が支払えなくて、絶滅した種もあると聞いたことがあります。
このコストの軽減の為に、ますます将来に備えて、自動化することが重要だという気になってきますが、しかし、将来に備えると言っても、一体何をすればいいのでしょうか？何から自動化していくべきなのでしょうか？また疑問が増えました。
（あと、さらっと人員が増える前提で書かれてるけど、そんな簡単に増えるものなの？というか、増えたとしてもその人に教えるコストもかかるじゃん。というか...)
シスアドとプロダクトの開発者は、大きく異なるスキルセットを求められます。そのため、シスアドと開発者は区別され、異なるチームに割り当てられます。間接的なコストは、このグループ化による分断に原因があると書かれています。
これらのコストは、２つのチームのバックグラウンド、スキルセット、動機付けがまったく異なることから生じるものです。この２つのチームは、状況を説明する際に異なる用語を使います。そして、技術的な解決策のリスクや可能性についても異なる推定をします。またプロダクトの安定性のターゲットレベルに対する想定も異なります。これらのグループの分断は動機づけにとどまらず、コミュニケーション、目標、そして最終的には信頼と尊重にまで及ぶこともあります。そしてその結果、病的な状態になってしまうのです。1
あったかもしれない会話
開発A君：一生懸命、サービスを作って、お客さんに気に入ってもらえれば、お客さんは喜ぶし、上司からも、褒められる。よし！頑張って、いいサービスをつくるぞ！
運用B君：お客さんが使っているサーバーに問題があっちゃいけない。万が一、止まってしまったら、たくさんの人に迷惑をかけてしまう。きちんとサーバーを管理しないと。
開発A君：B君、新しいサービスをつくったんだけど、サーバーに追加してもらってもいい？
運用B君：いいけど、この前の追加で問題起きたよね？再発防止のチェックリスト作ったと思うけど、それは全部クリアした？
開発A君：クリアしたけど、あのリストさ、無駄が多いんだよ。重要度の高いものだけに絞れない？
運用B君：でも、あそこに書いてあるのは、全部昔起きた障害の防止策だよね？やっとかないとまずいと思うよ？
開発A君：（うーん。チェックも大事だけど、早くリリースしたいんだよな。）
後日
開発A君：B君！サーバーに追加してもらいたい機能があるんだけど。
運用B君：チェックリストは？大丈夫？
開発A君：いや、今回は、大きい変更じゃなくて、マイナーアップデートだから、チェックしなくても、大丈夫だよ。あと、大した変更じゃないんだけど、ここだけチェリーピックしていい？
運用チームは、サービス稼働中に問題が起きないようにしたいと考えます。サービスの追加に関門を設け、問題を極力減らそうとします。
開発チームは、新しい機能を追加し、早くユーザーに届けたいと考えます。大きいハードルを越えることを避け、小さな変更を繰り返すようになります。
２つのチームの目標は基本的に対立関係にあるのです。1
どちらのグループも自分たちの関心事を優先させるため、塹壕戦のような状態に陥ります。1
歴史を振り返る
この歴史を振り返ると、初めは単に求められるスキルセットが違うという理由からチームとして分けられただけでした。
しかし、そのチームで自分たちの役割を果たそうとすればするほど、本来協力すべき相手と対立関係になってしまっています。その結果、相手を疑ったり、うまく欺く方法を考えるようになります。（その気はなくても）
目の前のタスクをこなすことに忙殺されてしまうと忘れてしまいますが、タスクをこなせば仕事になるわけではない。がっくりとしてしまいますが、これが現実なようです。
しかし、そんな残酷な現実も解決する方法はあります。
そうSREならね。
次回 サービス管理：SREのアプローチ編
まとめ
- 構造が争いを生む。
- 相手のことを考えよう！
雑感
今日進んだページ数１ページ半、終わるのか？
まだ、イントロダクションなので、仕方ないですが、この本の後半ではトレーニングもあるらしいので、取り組んでみたいです。行けるのか？
引用
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 3-4