20200522 SRE Lounge #12 メモ

SRE Lounge #12

Alerting Strategy for Self-contained Team

メモ

  • SREチームとして自己完結化を目指している
  • SLI/SLOの先 -> アラート重要
  • SRE NEXT の続編の発表
  • SREがボトルネックにはなりたくない
  • 責任分解点
    • Infra Study でそのような話があったがそんなのはなくていいのでは?
    • ボーダーレスだ!(納得)
  • アラート
    • アラートのポリシーがない、複雑怪奇となっていた
    • ポリシーを定義し直し
    • いらないアラートを削除(リファクタリング
    • DATADOG で可観測
  • アラートのレビュー(大事)
  • SLOのためにアラートはある
    • 各チームは各チーム別のアラートとすべき
    • まだSLOアラートはきていない
    • WebDevはSLOだけ見ている

感想など

  • 責任分解点は、気になっていたが、現場感が少し見えた気がする
    • 一緒にやっていこうよ、ということ
  • レビューによって通知アラートを消したのは
    • 同じようなアラートとか
    • CPU系は消した(他で見れる)
  • 本番でくるアラートは対処できない
    • できるのであれば、先に直しておけよ!となる≒普通の障害対応
  • オンライン教育サービス
    • 大変だった。。
    • リモートの方がコミュニケーション取れている
  • SREが見ている監視項目(そういうのを見ているのか!)

Security / AuditabilityをSREチームの成果指標に加えた話

メモ

  • Security中心の事例紹介
    • 試行錯誤中(の発表とのこと)
  • マッチングアプリとしての責任重要
  • 課題
    • 責任所在があいまい
    • 局所的なセキュリティ対策だった
  • セキュリティチームを発足した
    • セキュリティの対応は、先延ばしとなることが多い
    • 見えないことが多い
  • SREとセキュリティチーム間で目標を明確にする
    • アラートインジケータを明確にした
    • 設定や定義の標準化を進めた
  • セキュリティアラートはちゃんと「確認」する必要がある
    • SRE本のSLO設計に繋がる
  • セキュリティツール
    • 専用の社内ツール
  • セキュリティパッチの自動化は断念した
  • 今日話したSLIは、SRE間と握るもの
    • KPIは別に持っている

感想など

  • 避難訓練、どれだけできているのだろう
  • セキュリティの監視は大変である
    • KPI->サービス->システム

SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ

メモ

感想など