SREとして仕事をするときに考えてること¶

最近 verda.fm というPodCastを始めた。チームメンバーと雑談したいってのが個人的なモチベーションなのだけど、それぞれのメンバーの持つスキルや考え方について話を聞くことでチーム内外にとってなにかいい感じの価値を産めるといいな〜とも思っている。まだ非公式非公認なのでテーマの選定とかにはかなり気を遣っている。大人だから分別はつけないとね。

さて、つい先日に次回の収録のテーマをどうするかをその回のゲストと話してるとき、こんなことを言われた。

「まんじさんにSREのことについて聞いてみたいです！」

...なるほど。考えてみれば、自分がどういうモチベーションを持って仕事を作ってるか、どういう考え方をベースに仕事を進めているかみたいなことをまとめたことがなかった。

PodCastでそういうことを喋るのは全然OKなんだけど、非公式非公認なので話せる内容にも限りがある。それを当日いい感じに分類しながら喋る自信はない。いい機会なので、収録までに外に出せそうなところをザッと書き下してしまおうと思う。

僕はかなり感覚派なのでここに書く仕事のやり方が読者の参考にならないかもしれないけど、ご容赦。

前提¶

まずは前提として僕がどういう感じの仕事してるかを簡単に。

Verdaという社内向けクラウドプラットフォームの開発組織で、SREに責務を持つチームに所属している
チームの中でも、プロダクト横断での仕組み作りや作った仕組みの導入なんかを担当している
個別のプロダクトに対して、既存のやり方を拡張したり改善したりという形で貢献することもある

仕事を探す、作る¶

「プロダクト or 単一のチームが持つ課題に対する改善の立案と実施」「Verdaの多くのコンポーネント or チームが持つ課題に対する(ry」のどちらかにおおよそ分類される。

状況の把握と課題の発見¶

どういうプロジェクトを立てるかを考える前に、兎にも角にも現状の課題を発見しないことには始まらない。

僕は「どのような課題が存在するか」ということを考えるために集めている情報を性質上大きく2種類に分類している。

1つ目は受動的に集まる情報。

例えば、SREチームにはVerdaのそれぞれのサービス(プロダクト)が直面したトラブルやサービスダウンなどのインシデントの情報が集まってくる。インシデント発生時のユーザ対応、解決のためのディレクションは基本的にSREチームの責務なので、ちゃんと仕事をしてればそのあたりの情報は勝手に蓄積されていく。

他にも、社内のユーザサポートも(今のところ)SREチームの仕事なので、プロダクトの仕様の不便だったり分かりにくいポイントや、安定性が低いユーザリソースの種類に関する情報も勝手にチームに蓄積されていく。

そういう情報を受動的に脳に流していくとなんとなく課題が浮かんでくるので、

課題をより厳密に定義するために必要な情報を収集するための仕組みを作る取り組み
課題を解決するための取り組み

みたいな形に明確化してプロジェクトの目的とゴールを設定している。1日で終わるようなことであれば文書にはせずにサクっとやってしまうことも多い。あんまりよくないかもしれないけど。

2つ目は能動的に集める情報。

「プロダクトの開発ユニットの週次MTGに参加する」「Slackのチャンネルで議論されてるトピックを追う」みたいなことを日常的にやることで、SREとして貢献できそうな課題を探している。

特に週次、日次のMTGに参加するのは情報のインプットに対する時間効率がいい。深い確認もサクっとできる。

ただ人手が足りないので、これは全てのコンポーネントに対してできている活動ではない。目と手と耳と口があと3セットずつ欲しい。

「近い将来スケーラビリティの問題にぶち当たりそう」だとか、「サービスの稼動に影響はないけどうまく動いてない要素がある」みたいな課題はこういう活動をしないと中々発見できない。

目的とゴールの具体化、プロジェクト化の流れは1つ目と同じ。

仕事の分類と優先度、対処方針とか¶

優先度は割と感覚で決めているんだけど、おおよそ以下のような順序。

課題の原因は明確に分かってないけど、ユーザに影響が出ているもの
- こういうのは大抵突発的に発生するインシデントとして表れるので、ユーザへのアナウンスや影響箇所の手動修正なんかをSRE主導で進めることが多い
- SREと開発チームのリードが協力して原因をなるべく早く特定するように進める。開発チームの方も手慣れたもので、体制はわりとすぐできる。
- 解決策の実装に時間がかかる場合は、ユーザリソースに出た影響の自動修正なんかの仕組みをSREが急いで作ることもある。
課題の原因が明らかになっていて、発生によってユーザに影響があるもの
- まあ大抵こういう課題は先に開発チームの方で拾われてるので、SREとしてプロジェクト化することは少ない
- SREが気付いたときには開発チームでワークアラウンドが作られてる、みたいなことも結構ある印象
- 僕個人の知見が実装やレビューに役立ちそうなら、優先して積極的に介入している
- SREチームで持っている仕組みやノウハウが役立ちそうなら、協業の立て付けをサクっと作る
内部ツールや基盤のトラブル
- 複数チームが使ってる監視基盤やインシデント通知システムに関するトラブルがこれにあたる
- 大抵SREがデザインして運用してるものなので、解決までの時間は割と早い
監視とかの機能の設計 or 実装漏れのフォロー
- 新規プロダクトのキックオフ時とかに監視回りのデザインについての議論をしたり、デザイン自体をレビューしたり
- 後から気付いたことについてはサクっと作って渡したり、目的だけを開発者に伝えたり。この辺は割と適当なプロセスでやっている。(雑という意味ではない
- 既にサービスインしてるプロダクトについても、基本的なプロセス監視のためのmetricが抜けてたりとか、そういう発覚に対する修正はちょくちょくある
現在存在しないけど、必要な仕組みの開発
- API Availability Rateの記録とかロギングパイプラインとかのサービス横断で統一したい仕組みの開発、導入
- この辺は自分のアイデアだけではなく、もっと上の人の思惑だったり描いてもらった絵を具体化することも多い

最後の2つは現状あんまりできてない。どうしても優先度が落ちる。この辺を今後はもっとやっていきたいけど、プロジェクト化するために把握すべき情報が多かったり、複雑な検討が必要だったりして中々難しい。なんだかんだマンパワーが欲しいという結論になる。

やり方を決める¶

「マニュアル操作で何かをしましょう」みたいなものを解決策にはしない。特定のプロダクトの文脈に閉じた解決策ではなく、同じような課題を抱えたプロダクトが他にないかを調べて可能な限り汎用的な手段で解決する。できるだけ開発者が意識するものごとを減らす。

ある課題を解決しようとしたときに、その解決策によって対象チームの手間の合計が増えるような手段は取らないというのが基本的な方針。エンジニアとして、そういう手段を選んでドヤることは死んでもしたくないという謎のプライドがある。

SREの仕事が多少増える、みたいなのは妥協してしまうこともある。いいことではないけど、プロダクト開発チームに手間を押し付けるよりはまだマシだと感じる。

仕事を進める¶

SREという立場で仕事を進める以上、その成果はそれぞれの開発ユニットが管理してるプロダクトコードの変更やプロダクトのデザインへの要素の追加という形をとることになる。

なので、何か仕事をするときには対象のプロダクトの開発者たちと入念に意識を合わせるようにしている。立案段階、実装段階、導入段階、すべての段階でちゃんと情報を出す。

たまに誤解が発生したりもするけど、まあそれはお互い人間だからしゃーない。誤解の発生自体を根絶することはできない。

そもそも誤解の発生自体は悪だと思ってない。誤解の解決の過程で生まれるアイデアもあるし、施策の根本的な問題に気付くこともあるので。

とはいえ誤解の発生を最小限にするために努力することは正義だと思うし、面倒だけどちゃんとしようと頑張ってる。

大体こんな感じ。収録中に違う質問がでたら、それに関するトピックを追記するかも。