本投稿は、さくらインターネットアドベントカレンダー2022の14日目の投稿です。
この記事では2022年7月に発足した「SRE室」という部署について+これまで私が取り組んできたお仕事の一部を紹介します。
はじめに
さくらインターネットへ入職しSRE室で働き始めてからもうすぐ半年となります。
febc-yamamoto.hatenablog.jp
新しい環境に慣れるまで苦労しましたが、ここ数ヶ月はだいぶ落ち着いてきており、最近は毎日の仕事がとても楽しく感じられています。
これまでSRE室としての取り組みをあまり紹介できていませんでしたが、せっかくのアドベントカレンダーという機会なのでここで紹介させていただきます。
SRE室の紹介
SRE室とは
2022年7月に発足したばかりの新しめの部署です。
以下のような企業理念/ミッション/ビジョン/バリューに従い日々の業務へ取り組んでいます。
企業理念とSRE室のミッション/ビジョン/バリュー
まず我々の企業理念は「やりたいこと」を「できる」に変えるです。
この理念の実現のために、SRE室として以下のミッション/ビジョン/バリューを策定しました。
ミッション
我々の提供するサービスやシステム、プラットフォームの信頼性を高めることで、弊社の直接のお客様はもちろん、
その先のエンドユーザー様、ひいては社会そのもののDXを支えていきたいです。
ビジョン
率先してSREのプラクティスを実践し、社内へ広め、サービスやプラットフォームの信頼性を高めることで価値向上をはかりお客様へより高い価値を届けます。
また、その活動は社内に留まらず、社員自らEnabling SREとなることでお客様や社外のサービスの信頼性向上にも携わっていきます。
バリュー
SREが強権を発動して決まりを押し付けるのではなく、一緒に手を動かすことを大事にしています。
SRE室のエンジニアだけがSREs(Site Reliability Engineers)となるのではなく、
Embedded SRE/Enabling SREとして一緒に手を動かすことを通じてSREの取り組みを拡散させていきます。
一緒に動く際もそれぞれが勝手に動くのではなく、密なコミュニケーションにより互いに期待値を明確にしておくことで
合意のない期待を防ぎ、互いに作業を譲ってしまう/お互いに押し付けてしまう、いわゆる「お見合い」状態を防ぎます。
さらにYou build it, you run it(自分で作って自分で運用する)をバリューとして掲げました。
この言葉は有名なのでご存じの方も多いかもしれませんね。
logmi.jp
運用のことを考える開発/運用からのフィードバックを受けられる開発をすることで運用性を向上させ、ひいては信頼性を向上させるという狙いです。
担当業務
現在メンバーは5人です。それぞれが異なる領域を担当しています。
例えばボスであるkazeburoさんは運用系の業務として以下のようなものに取り組んでいます。
www.janog.gr.jp
また、別のメンバーは社内Kubernetes基盤を担当していたりします。
knowledge.sakura.ad.jp
その他にも色々な業務がありますが、この記事ではこれらの中から私の担当業務の1つであるEmbedded SRE/Enabling SREとしての業務を例として紹介します。
Embedded SRE / Enabling SREとしてのお仕事の例
この記事では3つの業務の例を紹介します。
- チームとしての開発/運用体制作り
- 安心して開発/運用するための仕組み作り
- ポストモーテムの導入
Embedded SRE/Enabling SREとしてプロダクトチームと共に手を動かすのですが、その範囲は開発だけに留まらず、
チームビルディング、CI/CD、モニタリング、QAなど多岐にわたります。
また、1つのプロダクトチームに専属ではなく、いくつかのプロダクトチームを兼任するような形となっています。
まずはチームとしての開発/運用体制作りについて紹介します。
チームとしての開発/運用体制作り
これは先月から携わり始めたとあるプロダクト(以下プロダクトAと表記)での取り組みです。
プロダクトAは結構歴史のあるプロダクトで、すでにユーザーも一定数付いており一見順調そうに見えるのですが、いくつかの課題/負債も抱えていました。
- 問い合わせへの対応速度が他チームと比較すると遅く見える
- 障害対応作業でのオペミスによる2次災害が発生していた
- ドキュメントが乏しく、アーキテクチャの全体像が掴みにくい
- アーキテクチャの全体像が掴みにくいせいでソースコードも追いにくい
- テストコードが網羅的ではなく手作業でのテストが大変そう
そこでSRE室として何か手伝いたいと思いプロダクトAチームへジョインすることにしました。
まずチームに入り、雑談会を通じて問題探し
まずはチームメンバーとの雑談会を通じて各メンバーの課題に対する温度感や悩みなどの思いを共有する場を設けました。
その場で以下のような問題も見えてきました。
- リモートワーク化が進んだことや中心的な役割を担っていた担当者の退職などによりコミュニケーションが減った/分断された
- 開発者の担当領域が分かれており、互いに他のメンバーの担当領域についてよく知らないという知識の分断状態となっている
- 開発開始当初と現在とでプロダクトに求められるものが変化し、信頼性や拡張性により高いレベルが求められるようになった(が追いついていない)
なぜ現在のようなアーキテクチャになっているのかといったあたりの背景/仕様についても雑談を通じて少しずつ見えてきました。
最初の一手: コミュニケーション経路の確保/整備
少しずつ問題は見えてきましたが、すでに動いているプロダクトにいきなり大鉈を入れるのはリスクが高く、また限られた人員でうまく回していく必要もありましたので、
まずは小さい改善を繰り返すことでゆっくりと信頼性を高めていく方針としました。
このための最初の一手としてコミュニケーション経路の確保/整備をしました。
まずはスクラムのデイリースクラムのように同じ場所/同じ時間に朝会というミーティングを開催することにしました。
チームメンバーそれぞれが抱えている仕事やその進捗状況、どのようなことで悩んでいるかを共有する場としています。
また、朝会で扱いきれないような課題については定例会ということで少し長めに時間をとって話す機会を設けました。
たくさんの課題がありますが、毎回どこまで/どれからやるかを参加者全員で話し合い、2〜3テーマをピックアップしてワイガヤする場になっています。
なお、さくらはリモートワークを前提とした働き方を採用していますので朝会/定例会はもちろんオンラインで行います。
次の一手: 「個人からチームへ」活動
チーム内でこまめにコミュニケーションを取る経路が出来たので、さらに一歩進めて各メンバーが個人で進めていた業務をチームで担当できるようにしてみました。
具体的には以下のようなところをチームで対応するようにしました。
従来はSlackなどで個人宛に問い合わせが来ていましたが、専用のSlackグループを作りこちらに問い合わせしてもらうことでチームとして問い合わせ対応を行うようにしました。
作業についてもZoomなどで画面共有しながら行うことでノウハウを共有できる仕組みとしました。
こまめな方向調整: ふりかえりの実施
これらの仕組みを導入してみて数週間経った時点でふりかえりを行い細かな方向調整をしました。
例えば朝会を見直し、担当業務についてはGitHub Projectを使うようにして可視性をあげるように変更しました。
チーム作りはまだまだ続く
まだまだ課題は山積みですがこまめな改善をしつつチームとして進んでいく体制が整いました。
今後のふりかえりで方針転換するかもしれませんが当面はこんな感じで少しずつ進めていくつもりです。
ということでチーム作りへの取り組みを紹介しました。
次はもうちょっと泥臭い開発/運用周りの業務を紹介します。
安心して開発/運用するための仕組み作り
前述のプロダクトとは別のプロダクト(以下プロダクトBと表記)での取り組みについてです。
プロダクトBチームへは私がバックエンドの開発の担当という形でジョインしました。
こちらのチームはある程度チームとして動く体制が整っていましたので、プロダクトの主機能の開発に加え、CI/CD、モニタリングなどの面の改善に取り組みました。
安心して開発/運用するための課題
プロダクトBチームへジョインした当初、作業をする中でいくつかの不安を感じていました。
- コード品質が下がることへの不安
- テスト不足による不具合混入の不安
- リリースなどの運用作業でお客様への影響が発生してしまうことの不安
- アプリケーション内部の動きが見えないことへの不安
これらの不安を解消し、安心して開発/運用できるようにすることはそのまま信頼性向上に繋がると判断しこれらの課題に取り組みました。
取り組み一覧
品質低下の防止
- golangci-lintの導入
- shellcheckの導入
- 単体テストの充実/テスト環境のDockernize
- 日次E2Eテストの導入
プロダクトBはgoとbashを主に利用していましたのでlinterとしてgolangci-lintとshellcheckを導入しました。
また、プロダクトがsystemdに依存しており、手元のマシン(mac/windows)からテストし辛いという問題がありました。
対応として外部環境への依存部分は極力切り離した上で単体テストを充実させると共に、Docker上でも動かせるようにすることでテスト環境構築を容易にしました。
加えてE2Eテストを充実させ、毎日実施することでエンドツーエンドでの問題発生を早期発見できるようにしました。
CI/CD
CI/CDの仕組みも整えました。さくら社内ではDroneやGitHub Actionsが使われていますが、どちらかというとDroneの利用が多そうだったのでそちらに合わせました。
運用面を考慮したソフトウェア改善
- 起動バージョン誤りを防ぐために実行ファイルへコミットハッシュの埋め込み
- デプロイを安全に行うためのGraceful Shutdown実装
- systemdユニットの再起動を安全に行えるようスクリプトを改善
- 依存モジュール更新などの運用をスクリプト化
更新などの運用作業時にお客様へ影響を出さないための仕組みや作業を楽にするための仕組みを作りました。
具体的にはAPIサーバへのGraceful Shutdownの実装などがあります。
デプロイ時はAPIサーバの実行ファイルの更新のためにAPIサーバの再起動が必要なのですが、
APIサーバがリクエスト処理中に再起動をかけてしまうとそのリクエストはエラー扱いとしていたため、再起動時にリクエストを投げていたユーザーには影響が出てしまっていました。
Graceful Shutdownを実装することでお客様への影響なくAPIサーバの再起動ができるようになりました。
監視
サービスメトリック監視を導入し、アプリケーション内部の状況の見える化を行いました。
安心して作業できるようになったので次の段階へ
これらの取り組みである程度安心して開発/運用できるようになりました。
次は生産性の改善に取り組みたいです。
Four Keysの計測など、まだまだ手を付けられていない物がたくさんありますので順次進めていきます。
ここまでいろいろな改善をしてきましたが、それでも障害は発生する物です。
次は発生してしまった障害を活かすためのポストモーテムの導入について紹介します。
ポストモーテムの導入
こちらは今取り組んでいる最中です。
将来的には全社的にポストモーテム文化を導入したいところですが、まずはSRE室の身近なところから実施してみてから徐々に広げていくつもりです。
このために以下のような取り組みを行いました。
- ポストモーテムのためのテンプレート整備
- ポストモーテムのレビューの仕組みを整備
ポストモーテムのためのテンプレート整備
テンプレートとしてSRE本の付録Dを利用することにしました。
www.oreilly.co.jp
シンプルで必要十分な項目が網羅されていますので、まずこれで運用してみて必要に応じて項目の増減をする方針です。
ポストモーテムのレビューの仕組みを整備
また、チーム単位でのポストモーテム実施時 or 実施後にチーム外の人からレビューしてもらえるような仕組みにしました。
SRE本でもベストプラクティスとしてポストモーテムをレビューすることが推奨されていますしレビュー大事ですよね。
ポストモーテムのレビューについてはPagerDuty Incident Responseにも項目がありますね。
response.pagerduty.com
ポストモーテム周りの仕組みを整備しましたが、いつ実施するのかの基準やどうやって結果を社内に展開していくかはまだ検討中です。
こちらは文化の浸透まで時間がかかるでしょうから気長に進めてみるつもりです。
終わりに
ということでSRE室や取り組んでいる業務について紹介しました。
この他にもトイルの削減のための自動化やプロアクティブな対応のためのモニタリング基盤の整備など面白い業務がたくさんあります。
これらはまた機会があれば紹介させていただきます。
以上です。
