SREに入門しよう 株式会社ユニクエスト 長谷川広樹 github.com/hiroki-it @Hiroki__IT

自己紹介 ▼ お仕事 最近：クラウドインフラ、IaC、CICD、... 以前：DDD ▼ 関心のある技術領域 ・クラウドインフラ ・IaC ・DDD github.com/hiroki-it @Hiroki__IT 長谷川 広樹 (はせがわ ひろき) 株式会社ユニクエスト

目次 ■ SREとは ■ （僕が思う）SREに必要な思想と技術 ■ Goによる厳格なルールに基づいた基盤実装 ■ モニタリング ■ オンコールとインシデント対応 ■ SLI/SLO ■ エラーバジェット ■ ポストモーテム ■ まとめ ■ カンファレンス

SREとは SRE：Site Reliability Engineering（サイト信頼性エンジニアリング） Googleによって提唱されたシステム運用や自動化に関連する開発 Site Reliability Engineering by Betsy Beyer, Chris Jones, Niall Richard Murphy, Jennifer Petoff

SREとは SREは何をすればよいのか...？

（僕が思う）SREに必要な思想と技術 ■ 稼働し続けられるシステム作り 　・Goによる厳格なルールに基づいた基盤実装 　・モニタリング 　・オンコールとインシデント対応 　・SLI/SLO 　・エラーバジェット 　・ポストモーテム 　・クラウドインフラによるマネージドなインフラ（今回は割愛） 　・セキュリティ（今回は割愛） 　・Production Readiness Review（※マイクロサービスで使用されるルールのため割愛），など... ■ スケーラブルなアプリケーション開発を生み出す環境作り 　・マイクロサービス，Kubernetes，CI/CD，IaC，トイル撲滅，など...（※今回は割愛）

Goによる厳格なルールに基づいた基盤実装（１） ■ Goのメリット ・データ型の扱いに非常に厳しく，開発時にバグを検出可能． ・ブラックボックスになりにくく，可読性が高い． ・処理速度が速い． ・同期処理と並列処理を簡単に書き分けられる（※非同期処理との違いに注意）． ・他の静的型付け言語（Java，C）よりも学習コストが低い． など... 堅牢なバックエンドを実装できる（例：決済系など）

Goによる厳格なルールに基づいた基盤実装（２） Goの導入を実現させる！ 一緒にGoに挑戦していきましょう！ 僕一人だと力に限界があります（切実）！ 知見を共有し合って，お互い爆速成長したい！ 僕も勉強中なので，知見共有させていただきます！ 僕のリポジトリ：https://github.com/hiroki-it/notify-slack-of-amplify-events

モニタリング ■ モニタリングすべき４大シグナル 　・レイテンシー（リクエスト到達まで＋処理終了からレスポンス到達まで） 　・トラフィック（とあるネットワーク地点でのスループット） 　・明示的エラーと暗黙的エラー 　　（400/500系異常レス + 後述するSLO未達やAPI仕様不一致の正常レス） 　・サチュレーション（システムの利用率の飽和度．「サチる」はよく使う） ４大シグナルは注視しよう！（自戒）

オンコールとインシデント対応 ■ オンコールとインシデント対応とは 　何らかのインシデントをチャンネルに通知するようにし，通知を受けて対応すること． 　当番制にしている会社もある． ■ インシデントとは 　エラーを含むシステム的に良くない事象のこと． 参考：https://backlog.com/ja/blog/on-call-system-for-backlog-developers/ 明示的エラーと暗黙的エラーのオンコールは必須！

SLI/SLO（１） ■ SLIとは：Service Level Indicator 　サービスレベルの指標とするメトリクスのこと． 　・サーバ稼働率 　・データベース稼働率 　・レイテンシー 　・レスポンスタイム 　・レスポンスのステータスコード率

SLI/SLO（２） ■ SLOとは：Service Level Objective 　SLIとして採用した指標の目標値のこと． 　・サーバ稼働率（日当たり0.1%のダウンタイム発生） 　・データベース稼働率（日当たり0.1%のダウンタイム発生） 　・レイテンシー（日当たり0.1%までのレイテンシー増加） 　・レスポンスタイム（日当たり0.1%までのレスポンスタイム増加） 　・レスポンスのステータスコード率（日当たり99.9%の200レス）

エラーバジェット ■ エラーバジェットとは 　・前述したSLI/SLOを決めたうえで設定． 　・年間や月間のエラーやダウンタイムがSLOに達するまでは， 　　これらが起こることを許容できる． 参考：https://www.redhat.com/ja/topics/devops/what-is-sre ダウンタイムをどの程度発生させてよいかの目安になる． ビジネスより技術を優先するときの意思決定が早くなる．

ポストモーテム ■ ポストモーテムとは 　障害報告書とは異なり，原因特定とシステム改善に重きを置いた報告書のこと． 　（タイトル・日付・担当・原因と対応・システム的/収益的な影響・幸運だったこと・仕組みの改善策・タイムライン） ■ 留意すること 　・作成に当たり，担当者を絶対に責めない．障害は誰のせいでもない． 　　（★最重要であり，必ず守ること） 　・対策は「以後は注意する」ではなく，再発しない仕組み作りになるように． 　・多くの人に情報を共有すること． 参考：https://qiita.com/an_sony/items/0565ad980f9097c76d11 エンジニアリングの心理的安全性を高めて挑戦しよう！

まとめ 今すぐ使えそうなSRE用語は どんどん使って SREチームさらにはシステム課全体の 共通言語にしていきましょう！ (「サチる」はすぐに使えます)

カンファレンス ■ SRE Lounge：https://sre-lounge.connpass.com/ ■ SRE NEXT：https://sre-next.dev/

最後に 改めてGopherくん 超かわいい!!! by Takuya Ueda (https://twitter.com/tenntenn) The Gopher character is based on the Go mascot designed by Renée French.