最初に下記記事を書いてから半年以上が経ったので再度まとめていきたいと思います。
【SRE】SRE業務1ヶ月で考えたことをまとめてみた - Qiita
※あくまで考えたことなので、実践できていないところも一部含めております
また今回の経験を通して下記の記事が非常によくまとまっていることを痛感しました。
2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
大きな枠組み
個人的に下記の大きな枠組みに分けてみました！
これをベースに書いていきます。
- SRE
- DevOps
- データ分析基盤
常に意識すること
- 発生頻度
- 発生した場合の復元可能性
- 発生した場合のインパクト
- データが漏れたらどうなる？
- ビジネスに与える損害額は？
- 開発工数
SRE
障害検知
障害が起きた時に、どのようにその障害を検知して、開発メンバーに知らせるかを考えます。
システムを構築した際、ここが最優先でやるべきところだと思っています。
ここの部分は主に監視と呼ばれており、以下の4つで監視できると思います。
- メトリクス
- リソース
- CPU、Memory、I/O、Network
- イベント
- デプロイ
- リソース
- パフォーマンス
- バックエンド
- どこのapiがボトルネックになっているかを判定します
- NewRelicだと
Apexが一つの指標になります
- NewRelicだと
- どこのapiがボトルネックになっているかを判定します
- フロントエンド
- TODO
- バックエンド
- ログ
- ログレベルの基準設定と周知
- Slackの設計
- 外形監視
Datadogとかが一括管理できるので便利ですね。
検知の仕組み
どこに通知させるかは、slack一択なのかなと思っています。
しかしただSlackに通知させるのではなく、Slackのチャネルの設計、チャネルに含める開発メンバー、その後の対応などを考慮して設計する必要がありそうです。
- 誰がSlackのメンバーに招待すべきなのか
- チャンネルは幾つに分割すべきなのか
お問い合わせしてもらえるようにする
お客さんからサービスおかしいですよーと言ってもらえるようにしておきます。
使用しているSaaS・Cloud等による障害
GCP、AWSの各サービスの可用性を把握し、落ちた時に検知・対応できる体制を整える
障害を起こしづらく
障害を 0 にすることはできませんが、減らすことは可能です。
プロダクションにデプロイするまでにどこまでするのかが論点になりそうです。
テスト
- テスト基盤と実行環境の整備
- カバレッジレポート
- 何でカバレッジを担保するのか？
- E2E?
- 何でカバレッジを担保するのか？
- カバレッジレポート
- チームにテスト書かせる
- TODO
セキュリティ障害・セキュリティインシデント
- 脆弱性診断
- これ自社でできると最高
- TODO
- これ自社でできると最高
- 権限の管理
- AWS IAM
- GCP IAM
負荷による障害
スケーラビリティ
- ロードバランサーを正しく運用する
- L7、L4の違いを理解して運用する
- DBのスケールの限界や、その対応方針を固めておく
- ここはメトリクスでCPU、Memoryを監視をしておいて、どこのタイミングでスケールアップするのか決めておく必要がある
- 負荷試験
- 今後どのくらいアクセスが増えるかを確認し、設計に落とし込んでいきます
障害復旧
障害が起きても再起動・再構築できる
- ダウンタイム短くする
- マルチリージョン
- Infrastructure as Codeでコードをソース化
- k8sのマニフェストファイル
- kustomize、hemlで管理する
- Terraform
- CloudFormation
- k8sのマニフェストファイル
- 自動復旧
- コンテナが潰れた場合は、k8sが勝手にpodを再起動してくれる
障害が起きた際に切り戻しができる
- Revertを即適用できるなど
- ブランチ戦略
- Git Flow
- Github Flow
- GitLab Flow
- ブランチ戦略
- DBのバックアップからの復元
- マイグレーションを戻せるようにする
チームの対障害オペレーションフローの構築
- 業務時間外の対応方針
- 業務時間内の意思決定フロー・実施フロー
障害が起きても逃げ場がある
マルチクラウドでの基盤構築など
予算管理
GCPでもAWSでも使用する際には予算を設定し、次ごとに予算内に入っているか確認するようにします。
半月くらいでその月の支払いがどのくらいになるか予測しておきます。
また予算オーバーになるようなら、何が原因でオーバーになっているのか調査します。
結果によっては、予算を変更する相談をビジネスサイドと詰めていきます。
DevOps
開発環境構築のスムーズ化
- コンテナでの運用(docker)
- ローカル、ステージング、プロダクション環境での環境差分をなくしていく
- 開発環境の速度改善
- ローカルのDockerのデバッグ
デバッグをしやすくする
- ログ基盤の整備
- 出力先の設置と接続
- datadog
- どこに何が出力されるのか
- どうすれば出力できるのか
- 出力されたものをみる権限付与
- 出力されたものの読み方
デプロイがスムーズに行える
- CI/CDによる自動化
- CircleCI
- Travise CI
- AWS CodeDeploy
- GCP CloudBuild
- buildの高速化
- Dockerのデバッグ
- CircleCIのデバッグ
- 高度なデプロイ
- ブルーグリーンデプロイ
- GAE
- カナリアデプロイ
- Spinnaker
- GitOps
- その他
- Skaffold
- ブルーグリーンデプロイ
サーバーレスの活用
これどこに入れるべきか悩みましたが、DevOpsに入れておきますw
GCP
- CloudFunctions
- Cloud Run
【GCP】えっ、Cloud Functionsだけじゃないの？ - Qiita
AWS
- AWS Lambda
データ分析基盤
分析基盤構築
- データレイク
- GCS
- AWS S3など
- データウェアハウス, データマート
- BigQuery
- Redshiftなど
- データ分析
- redash
- エンジニア以外でこの数値を管理するか
- スプレッドシート
データ分析のログ基盤
- 分析用ログ
- アプリケーションエラーのログとは異なるログ
- 何にログをはかせるのか
- fluentd
- Embulkなど
Embulkを利用したデータ転送基盤の構築 - ZOZO Technologies TECH BLOG
分析文化の醸成
- ビジネス側がどのように分析できるようにするのか
- SQLをビジネス側にどこまで普及させるのか