トップ > SRE > SRE NEXT から学べることは沢山ある。Vol.2

SRE NEXT から学べることは沢山ある。Vol.2

SRE

こんにちは。
挨拶はそこそこに、本日は『SRE NEXT から学べることは沢山ある。』第二弾です。

今回は40分枠・3つのセッションについて記していきます。メモの分量多め。


1. SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

清水 勲さん　株式会社ミクシィ

youtu.be

これがわかる

  • SREがどうセキュリティに取り組むか？について各種プラクティス
    • SRE(信頼性)とセキュリティの両立
    • 環境づくり
  • セキュリティへの取り組み事例からの学び

印象的だった言葉

  • class SRE implements DevOps
    • SREの役割はまだ初期段階、役割の定義・理解が課題
    • SREは技術的スキルとソフトスキルの両方を備える必要がある
    • 「脅威を理解する。多層防御をする。シンプルにし、安定稼働する。」
    • 「信頼性とセキュリティはソフトウェアとシステムのライフサイクルに不可欠」
  • チーム間のコミュニケーション大事
  • パブリッククラウド上では自分たちで構築する部分のセキュリティの責任を持つ

所感

SREが「ソフト」面の活動を求められる役割であることがよくわかる。
セキュリティ強化の活動はReliability（信頼性）を保つための活動と同じ道の上にあるものだと認識した。例えば他チームとのやりとり等のソフト面や、IaC、モニタリングにポストモーテムなどの技術的な活動どちらも、全体的に「見通しをよくする」ことが信頼性・セキュリティ両面を高めていくものなのだと再確認。当たり前をしっかりやる。
個人的に、最初に「みてねを使ってらっしゃる方〜」と言って手が挙がるのが素直に羨ましかった。そういうサービス作りたい。


2. ZOZO MLOpsのチームリーディングとSRE(Engineering)

瀬尾 直利（そのっつ）さん　ZOZOテクノロジーズ

youtu.be

これがわかる

  • SREチームリーディングの心構えと手法
  • チームリードしていく中で起こった事象と対応
  • MLOpsのことを少し

印象的だった言葉

  • チームの方向性を行動目標、意義目標、成果目標で定義する
    • 社内の期待を裏切らない
  • スムーズなプロジェクト進行のために、自分に依存性のあるタスクをなるべく作らない
  • 業務フロー自体を見直すこともある
  • 何か問題があっても「仕組みを憎んで人を憎まず」
  • スキルアップできる環境づくり
    • 当たり前のレベルを上げる
  • ルールより文化
  • 技術力でぶん殴る
  • EMの仕事はメンバーの給与を上げること、メンバーが成果を出せるようサポートすること

所感

まず、そのっつさんの網羅性に驚愕した。業務・技術面だけでなく心理面でもチームリードをしながらエンジニアリングマネージャもこなす。しかもそれらの活動が相互作用している。
チームリードする立場でなくても、参考になるポイントが必ずあります。エンジニアの「当たり前」の技術レベルを上げることや、ルールより文化・技術力でぶん殴る！などのお話はぜひ動画で詳細を見て欲しい。※28:00~ごろ
「細部を追う技術力がないと、サービスを安定化させるのは難しい」というのも実例を交えたお話で肯ける。全体的にそのっつさんの言葉に説得力があるのは、しっかり「背中を見せているから」だなぁ。


3. サイト信頼性エンジニアリングの原則

山口 能迪さん @ymotongpoo　Google Cloud

youtu.be

これがわかる

  • SRE全般の基本的な・でも一番大切な概念の話
  • O11yとSREは切っても切り離せない関係

印象的だった言葉

  • "Hope is not a strategy" オペレーションを積極的にエンジニアリングに置き換えていく
  • 「複雑性」の要不要を判断し、不要を取り除く
  • 「一貫性」は単純性と一体
  • アラートには「思いやり」が必要
  • ユーザ体験が壊れていないか、がアラート発信基準（SLO違反になる危険性がないならページしない）
  • コンピュータにできることは全て任せる
  • エラーバジェット例：残りの0.1% の予算＝余裕を活用することが大事
  • 変更が生じるときにはロールバック方法を一緒に出す
  • ポストモーテムはSREで一番大事
    • 人間を原因にしない
      • プロセスや技術を改善していくこと

所感

SRE本やgoogleのSREサイトでも紹介されているような、基本に忠実な考え方と業務の事例を交えたお話。本を読んだ人にとっては良い振り返りになるし、読んでない方でもSREの大枠を理解できると思う。
特に「エラーバジェット」「ポストモーテム」は重要視されていて、お聞きしていてなるほどなぁと思う点があったので記しておく。

  • エラーバジェット
    • 残りの0.1% の予算＝余裕を活用することが大事
      • 時間が決まることで、何をしていいか・ダメかが分かりやすくなる
      • 厳しすぎると変化が遅くなる
      • 守れないのなら、何かが間違っている
  • ポストモーテムでは以下を考える
    • エンジニアリングでポジティブに防ぐ方法
    • 検出するまでの時間を減らす方法
    • 次に同じような障害が起きたときに深刻度・影響度を減らす方法
    • 障害が起きちゃった時の早い回復方法


今回はここまで。