話題の職種SRE
今年はSREが話題になった。SRE本が出て広く読まれたということもあるが、バズワードになることなく実体が伴っているということは、SRE Advent Calendar 2018 - Qiitaの各記事を見ても明らかだろう。
ただ、SREと呼ばれる役職はやることが多岐にわたるため、「SREの部隊を作る」と言われた時の不安も多い。
運用エンジニアを補充するための方便
SRE本第1章には、システムの運用をソフトウェアエンジニアが行うようにしたとある。運用を行うのだからと、従来の運用(devとopsに分断した状態のops)のミッションのまま、「SRE」と偽って人を集めるところがでてくると、不幸だ。
第5章に、「運用業務を、各人の作業時間の50%以下に抑えるという目標」とある。つまり、SREチームは運用チームの単純な言い換えではないのだ。運用業務以外のエンジニアリング、つまり、ツールの作成や信頼性のための機能の追加、モニタリングのセットアップなどの活動が、業務時間の半分を超えるような職種だ。「問題が発生したから対処する」という受け身の運用チームとは、性格が全く異なっている。
「攻めの運用チーム」と仕事をしたという記憶が残っていないので、SREは運用チームとは異なった職種であるとは言い切れないのだが、少なくとも、「受け身の運用チーム」とは異なった職種であろう。
class SRE implements DevOps
悩んでいた一文ではあったのだが、Advent Calender 24日目のSRE風のインフラエンジニアにならないために - Work Recordsを読んで納得。確かに、高速にリリースできれば問題が起きた時も ロールバックする／修正版をリリースする どちらの手段も有効だろう。
しかし、devが「高速にリリースできる」ように作っていないと無理な話だし、opsにはそれを実行するための腕が必要になってくる。devとopsが顧客へのサービス提供という点で協力し合う文化が醸成されていなければ、難しい話だ。
- 「運用回避」のまま放置されている障害
- devには公開されていない本番環境のリソース使用状況
- リリースに立ち会わないdevチーム
- devにエスカレーションされない障害通知のチケット
監視
SRE本第3章、エラーバジェットの話。客観的なメトリクスを定義し、そこからSLOとエラーバジェットを規定する。devとopsの対立を、「エラーバジェット」を導入して解決する。ここで重要になってくるのが、定義したメトリクスの監視。
自社のサービスの監視項目を見てもすっきりしなかったので、考え直してみた。
- インフラレイヤーでの監視
- サービスレイヤーでの監視
- devが気にする項目の監視
サービスレイヤーでの監視は、インフラレイヤーよりももう少し大きな視点から見た監視。極端なことを言えば、サーバが1台止まっていても、ちゃんと可用性を確保する構成になっていて提供サービスに影響がなければ「問題なし」と判断する。
devが気にする項目の監視は、APMと呼ばれる分野かもしれない。サーバが動いていても、リクエストに対する処理の1つがエラーになったらNGと判断する。
この３つに分類してみると、サービスレイヤーでの監視を行うサービス(商品)は少ない気がする。URL外形監視をおこなう - Mackerel ヘルプなどのURL監視や、LoadBalancerでのレスポンスタイムやHTTP Statusの監視くらいか。
ただ、[SRE Advent Calendar] 監視システムの特徴から考える監視設計のポイント - かつひささんの日記にあるように、SREの成果を見るには信頼性を計測する必要があるので、そう簡単な話では済まないはずだ。サービスにするほどのニーズが集まらない(分散してしまう)とか、そもそもSREはプログラムを書ける人だから自分たちで作ってしまっているとか、そういった事情があるのだろう。
監視の目的がサーバ監視とは異なるから、従来の運用チームが使っていた仕組みではうまくいかない可能性も考えておく必要がある。
まとめ
信頼性の問題は、SREという役を作れば解決するものではない。そういった役割を作れるだけの文化が醸成されていないかぎり、そして、役を作れば解決するという考えを改めない限り、どんなことをやっても解決しないだろう。
