SRENext行ってきた

会社ブログとの連携用にはてな垢作ったけどずっと放置してたのと、今年の目標最低毎月1本と会社Slackで宣言したのでやっていきます。

起源?母体?SRELoungeには一度だけ聞きに行かせてもらいました。そのときのパネルディスカッションや懇親会で聞いたり話したりしたことが衝撃的というか自分にとってすごく得られるものが多かったので、本イベントの告知があってからもずっと楽しみにしてました。

(早めに会場についてTully'sで悠々とお茶を飲みながらOpen＆ヨガ講座待ち...のはずが皮肉なことにこのタイミングでアラートを受けてKeynoteにも間に合わなかったのが悔しい...)

とりあえず当日参加したセッションのメモから思うところをピックアップしてまとめます。

イベントを通して思ったこと

  • 自分は目の前の小さなことに拘泥して、全然大きな流れを意識できてなかったなぁと痛感、とりあえず順番にやっていこうと思った
    1. 「理想と現実のギャップを知る」
    2. 「できることから」「完璧じゃなくても」
    3. 「先をみて決断していく」
  • タスクの分割が甘いから自分の首しめてるのを痛感
  • 「専門職としてのSREは減っていく」はパネラーの方の間でも意見が一致してた
    • 属人化排除と「巨人の方に乗る」突き詰めるとそうなるなぁと
    • 真っ先に思い浮かんだのはこの言葉

※ 以下、スライドの下に色々書いてるのは私の感想であり登壇者さんの発言とは異なる場合があります

絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

  • 「段階ごとにできることから」「最初はtoilも障害も受け入れるしかない」って言葉が印象的
  • いま自分が「ああまた防げなかった...」って後ろ向きな気持ちになってしまうことが多かったので
  • ですが「できていないことがあった = できることが見つかった」と前向きに捉えて、とにかくもっと試してみようかと
  • 後半のメルペイにおけるSREチームの変遷の話は、1人から始まって7人体制のチームを率いる立場になるまでの軌跡はこれから自分がやってくべきことだなぁと...

パフォーマンスを最大化するための SRE のオンボーディング事例

  • オンコールのシャドウイングの話は面白かった
    • (よく知らないけど)手術を見学するようなイメージ?
    • 自分が教育実習行ったときも、他教科含めて授業を見学させてもらうことがあった
    • 確かに、やってみなきゃ出来るようにはならないけど、いきなり実際にやるのはハードルが高い
    • その間を埋める方法としてすごく良さそう
  • ざっくりいうと「一人前になってほしい」 は一人前が定義できてこそ言えるよなぁと
    • オンボーディングができる <- タスクがきちんと切り分けられている <- 責務やミッションが明確である

Practices for Making Alerts Actionable

  • ダッシュボードをロールごとに分けているらしい
    • 維持管理が大変そう
    • ロールが違うと技術的にもドメイン知識的にも知ってる範囲や触れる範囲がことなるのでそのほうが良いかも
    • 自分の周囲に目をやると
      • (普段運用系の作業をすることのある人は)メンバー間で触れる範囲に大きな差がない
      • なので、(まだ)ダッシュボードを作り分けなくていもいいかも
  • 構成図とお話にCloudWatchが出てこなかったので、「オンプレから移り変わってきた経緯からOSSベースの監視なのかな？」と思っていたら登壇者さんからTwitterで「使ってるよ！」と補足いただきました

SLO Review

  • ほぼ全員がSLOを知っていても実践できてる人は会場の1/4、Error Budgetまでできてるのは数名
  • Coursera あるの知らなかった
  • 「SLOはあることが大切だ」(某架空の総理大臣をイメージ)
    • 実際、設定しようとして取れてない、メタ情報足りないことに気づくメトリクスもあるし
  • 依存先(クラウドプロバイダ、または自社内部のAPIなど)のSLOを超えることはできない、勝手にそれ以上設定するのは無責任ですらある

スクラムを1年回してSREと開発組織がどう変わったのか

  • 言われてみれば SRE/Devの共依存 と「理想的な協調」って全然違う
  • 自分の周りをみれば、自身はもともとバックエンド開発が中心だし、プロダクトチームも自身でインフラ触れる
    • タスクを誰にでも出来るように分割する の 「誰」にあたる人々のレベルが高いので、分割できてないのは自分の問題感...
    • その点ではある意味恵まれた環境なので、工夫してもっとProductivityとReliabilityのバランスを高く保ちたい

Designing fault-tolerant microservices with SRE and circuit breaker centric architecture

(※本記事を書いた時点でスライドの共有は見つからず)

  • ざっくりいうと、Circuit Breakerを含めSLOを真剣に守る仕組みを作ることで、思い切った施策もできるようになる
  • Cookpadさんの規模でも「小さいから何でもサポートすることはできない」という判断をする
    • 自分の環境はもっと小さいので、「制約による効率化」はもっと取り組んで良いかもしれない
  • (bonus talk)
    • on-callシフトは週単位が好きな人、日単位が好きな人、週末入るのが好きな人など色々居る
    • 会社で決めるよりチームで決めたほうが良い

Webサービスを1日10回デプロイするための取り組み

  • 終わりのキーノート
  • 「常にデプロイしていれば、デプロイが怖くなくなる」
    • デプロイは別にアプリケーションに限らない
      • サーバのプロビジョニング
      • terraformのapply
  • ざっくりいうと、スピードがないと10デプロイは無理
    • ピーク時、休前日はデプロイすべきではないことも勘案すると意外とデプロイできる時間は短い
    • CI・テスト・ロールバックも含めて、単にアプリケーションを置いて終わりではない
      • ロールバックのためには迅速なエラー検知が必要
      • test in production的な
    • 3分かかってるのが1分になる -> Twitterを見なくなる
  • コード書いた人がデプロイ
    • これは今の自分の環境もできてる(その過程をもっと手軽にすることはできるかも)
    • 最初にそのコード書いた人以外が、もっと気軽にContributeできるようになればなお良さそう