【勉強会レポート】SRE Lounge #12

SRE Lounge#12に参加してきました。
今回、初のオンライン開催だそうです。

SRE Lounge とは

イベントリンク
https://sre-lounge.connpass.com/event/175323/

SRE Lounge は、サイトの信頼性、エンジニアリング、スケールする分散システムに深い関心を持つエンジニアのための、オープンな集いの場です。
SRE の思想や考え方に興味や関心のある様々な人々と交流し、日々の現場の取り組みや研究成果を伝え、日本のエンジニア界隈を盛り上げることを目的としています。

サマリーと感想

Alerting Strategy for Self-contained Team

Quipperにおけるアラート対応のお話でした。
Quipperではアラートのレビューをデイリーとウィークリーで行っているそうです。毎回3つくらいまでアクションする必要があれば行っているということでした。
デイリーはQuipperはオンライン教育サービスということで、このご時世いろいろ大変だったそうで、デイリーでスタンドアップミーティングをする必要が出てきた中で、アラートについても見ていこうとなってやってみて良かったそうです。

以前はアラート対応に問題があって、それはポリシーがなかったそうです。
ポリシーを定義し直したというのはEmergency、Alert、Noticeのレベル分けしたというのと、プロダクトに分けたというのがあったそうです。また、アラートはSLOのためにあるということで、例えばCPUのAlertはSLOに影響しないのであれば必要ないという判断をしたようです。

また、開発側とSRE側で責任分界点はなく、ボーダレスであり、はみ出てお互いの領域に入るのは歓迎としているそうです。
SREは広くアラートを受けて、他の開発チームはSLOだけ見てればよくない?という考えにたどり着き、SLOに関連するものだけ受けているそうです。

また、SLOに関してもウィークリーでSlackチャンネルにアラートとして飛ばしているそうです。

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

エウレカの恩田さんの発表。SREチーム、セキュリティ部門、情シス部門のマネージャー。
会社や事業をとりまく変化としてリーディングカンパニーとしての社会的責任が最近重視されてきているそうです。

・何が課題だったか
セキュリティ対策の課題として推進力が不足していた(責任所在が曖昧で牽引役がいない)。
CTOや開発チーム、SREチームがそれとなく推進していた。
また、局所的なセキュリティ対策になりがちで、防御と検知に目が向きがちだった。

・何を始めたか
セキュリティチームを立ち上げた。
SREチームとどういうコミュニケーションが生まれて課題があるかという話。
状況の透明化とレポーティング、ロードマップの策定、予算と人事計画。
IR体制のブラッシュアップ、セキュリティトレーニングなど。

・何が起きたか
いい感じに物事が動き始めたが、課題も生まれた。
全てが順調なときにセキュリティは見えない、削減、延期可能なコストとしてみなされる。
脆弱性診断対応とか優先度が下げられる。
セキュリティのために最小特権という考えがあるが、一方でオペレーションのスピード阻害となりうる。
コミュニケーションコストの増加
セキュリティ診断のために構成図作ってとか
☓☓って何に使ってるの?どんな背景?みたいな

・何をやったか
3本の指針を元に摩擦の解消
■目標設計と目標の共有
セキュリティリスク(イベント)対応状況をチーム間共通の成果指標に
 SLI(目標収束日数以内に対応完了した案件数/全イベント × 100)
 SLO=xx%
■安全な選択をデフォルトに
タグによるストレージ、リソースの事故定義的分類など
■コミュニケーションの疎結合化とルーティング化
必要な人が必要な情報を自分でとりにいける状態

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

NewRelicの大谷さん。

ブログを2つ紹介してくれました。

モダンなシステムにSLI/SLOを設定するときのベストプラクティス

New Relic流、オンコールとインシデント対応の成功への道

オンコールで辛いのは営業時間外(深夜)なのでそこの回数を追う
オンコールの対応時間にかかった時間を追う
顧客より先にインシデントを発見することができたらそれはインシデントではない(とみなす)

この辺の話は面白いですね。
最近のnewrelicの機能はアラートを設定してなくても変化を通知してくれるらしい(ログイン回数がいつもより多いとか)です。