SSMJP-20221219-01-NLOG2N2

SREってなんですか 友人とMTUについての話していて、咄嗟に1492と言ったら、 友人から「MTUの上限値の話じゃねぇよ！！」と突っ込まれたので、 SREについて真剣に考えてみた。 @nlog2n2 Sekiguchi Toshihiro

本編

パンケーキ食べたい パンケーキを食べながら、 • 個人的にはGCP触りたい • 大規模運用手伝いたい • 監視設計させろ など、私が供述したところ、 友人とCI/CD の話になったので、 真面目にSREの仕事ってなんだろうな とちょっとだけ調べ考察してみたLTに なります。

SRE本

SREの仕事と思われるもの • 諸悪の根源の目次を流し見して、ざっくり内容を書いた SRE本 リスクの受容、サービスレベル目標 トイルの撲滅 分散システムのモニタリング、 アラート、オンコール対応 自動化 リリースエンジニアリング トラブルシューティング、緊急対応 インシデント管理 ソフトウェアテスト キャパシティプランニング、負荷分散設計 バックアップ・リストア設計 旧来のシステムエンジニア 非機能要件 独自ツールの作成と導入 （シェルやスクリプトの作成） 監視設計・障害対応（1次対応） 運用の自動化 リリースの自動化と検証 障害対応（2次対応） 障害対応の管理 QA作業 非機能要件 非機能要件

業務内容は オンプレミス環境のインフラにかぎっている

SRE本に対する考察

おそらくなんだけど（過激派） • 古くはシステムエンジニア、10年前はインフラエンジニアと呼ばれていた人た ちがSREに限りなく近いと思われる。 • 下手したら35歳以上でそれなりにシステムエンジニアしている人たちなら、 なんでも対応できる範疇な気がしている。 • 非機能要件の定義は必ずシステムを作るときにはやる。 • 今更エラーバジェット云々を言われても、何も新しくない。 （IPAの非機能要求グレードのレベルMAXぐらい）

クラウド環境の台頭 • タチが悪い状況として、クラウドサービスでシステムを組むことが多くなり、 クラウドシステムのインフラをやる人たちのことをSREと呼んでいる風潮があ る。 • なお、この人たちはインフラの興味がない人たちではないという排他的な属 性であって、他のレイヤーの仕事もなんとなくやって、趣味でアラート対応と かもやってしまう。

SREチーム 組織の立て付け

SREの組織形成 • 左図は私がふわっと思っているDevOpsチーム構成。 • DevOpsのチーム構成のまま、責任分界点と新技術の 領域を満たせば、ほとんどの組織でSREというのは可 能じゃないか？と考えている。 • 問題点 • ただし、今までDevOpsもまともに機能していない組 織の方が多いと思われる。 • サイロ化して機能していた組織が急にSREやれと言っ ても無理筋では？ • 勉強会、友人、仕事を通じて思ったことは、SREとい う役割は、あまりにも組織ごとにフワフワしてて、分 かりにくい。

技術要素

IaC

IaC • ネットワーク、ミドルウェアのコンフィグ管理となんら変わりない。 • 構文さえ覚えてしまえば、リリース作業＆エラー処理までしてくれるので、シ ステム構築の難易度は下がっている。（が、それが世間的には認識されていな い。。。）

キャパシティプランニング

クラウドのスケーラビリティ • オンプレはハードウェアの制限があるが、クラウド上だとその概念がない。 • 小規模サービスなら札束ビンタでOKということでエンジニアが甘やかされて いる。

負荷試験

負荷試験（検証） やれ

負荷試験（検証） • 負荷検証はQA段階でやることで、負荷検証していないシステムを導入してし まう場合は安定稼働の定義からも外れる。 • プロダクトの特性を知ることで、障害対応のパターンの原因は絞れるが、やっ たかやっていないかは、運用中に大きなプレッシャーにつながる。

監視

監視 買え

監視設計 • 運用設計と監視設計はセットのため、どちらが落ちてもいけない。 • サービスを止めないためには、運用設計は必須であり、そのための監視設計 だがそこが抜けていることが多い。 テンプレートの監視設計を入れて、運用設計は後から対応するという光景を よくみる。 • ZabbixやSNMPの工数を払うより、機微じゃない情報に関しては、SaaSの監 視は買った方が費用対効果が高い気がするが、そこの見積もりを取って、政 治的に旗を振れる人を見たことがない。

CI/CD

CI/CDは誰のものか • CIはアプリケーション担当、CDはインフラ担当のものであって、継続的なサ ービス提供には、どちらも不可欠だと思ってる。 • そのために運用設計の段階で、CI/CDに関するメンテナンスポリシーを作る べきだと感がているが、そうなっているところは見たことがないため、私の 考え方は間違えている気もしている。

CI/CD 運用のアンチパターン？ • 要件・外部仕様・内部仕様を書かない人たちにCIを許可するのは早すぎる。 • 残念ながらプログラマはドキュメントを書く人が圧倒的に少ない。 • プログラムを保守していた人が抜けるとCIが死ぬ。 これは安定稼働から違反している行動になる。 • リバースエンジニアリングを許容してはいけない体制が必要だと思われる。

ビジネス領域

費用対効果

ビジネス的にメリットある？ • 自動化する工数とデプロイのメリットちゃんと天秤にかけられてる？ • そもそもシステム化しなくても人経費にした方がビジネス的においしくな い？（手作業の方が圧倒的に安い＆他の会社の利益になる） • そもそもシステムのスケーラビリティを札束でビンタした方が安くない？ • 機会損失で失われるお金 < SRE 活動という認識できている？

おまけ

最近、脂がキツくなってきました

街角で見つけた良さげな図面