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

Posted: January 03, 2021

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

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

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

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

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

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

前提

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

仕事を探す、作る

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

状況の把握と課題の発見

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

やり方を決める

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

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

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

仕事を進める

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

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

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

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

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


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