Help us understand the problem. What is going on with this article?

【SRE】業務8ヶ月で考えたことをまとめてみた

最初に下記記事を書いてから半年以上が経ったので再度まとめていきたいと思います。
【SRE】SRE業務1ヶ月で考えたことをまとめてみた - Qiita
※あくまで考えたことなので、実践できていないところも一部含めております:bow_tone1:

また今回の経験を通して下記の記事が非常によくまとまっていることを痛感しました。
2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita

大きな枠組み

個人的に下記の大きな枠組みに分けてみました!
これをベースに書いていきます。

  • SRE
  • DevOps
  • データ分析基盤

常に意識すること

  • 発生頻度
  • 発生した場合の復元可能性
  • 発生した場合のインパクト
    • データが漏れたらどうなる?
    • ビジネスに与える損害額は?
  • 開発工数

SRE

障害検知

障害が起きた時に、どのようにその障害を検知して、開発メンバーに知らせるかを考えます。
システムを構築した際、ここが最優先でやるべきところだと思っています。
ここの部分は主に監視と呼ばれており、以下の4つで監視できると思います。

  • メトリクス
    • リソース
      • CPU、Memory、I/O、Network
    • イベント
      • デプロイ
  • パフォーマンス
    • バックエンド
      • どこのapiがボトルネックになっているかを判定します
        • NewRelicだとApexが一つの指標になります
    • フロントエンド
      • 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が勝手にpodを再起動してくれる

障害が起きた際に切り戻しができる

  • Revertを即適用できるなど
    • ブランチ戦略
      • Git Flow
      • Github Flow
      • GitLab Flow
  • DBのバックアップからの復元
  • マイグレーションを戻せるようにする

チームの対障害オペレーションフローの構築

  • 業務時間外の対応方針
  • 業務時間内の意思決定フロー・実施フロー

障害が起きても逃げ場がある

マルチクラウドでの基盤構築など

予算管理

GCPでもAWSでも使用する際には予算を設定し、次ごとに予算内に入っているか確認するようにします。
半月くらいでその月の支払いがどのくらいになるか予測しておきます。
また予算オーバーになるようなら、何が原因でオーバーになっているのか調査します。
結果によっては、予算を変更する相談をビジネスサイドと詰めていきます。

DevOps

開発環境構築のスムーズ化

  • コンテナでの運用(docker)
    • ローカル、ステージング、プロダクション環境での環境差分をなくしていく
  • 開発環境の速度改善
    • ローカルのDockerのデバッグ

デバッグをしやすくする

  • ログ基盤の整備
    • 出力先の設置と接続
    • datadog
    • どこに何が出力されるのか
    • どうすれば出力できるのか
    • 出力されたものをみる権限付与
    • 出力されたものの読み方

デプロイがスムーズに行える

サーバーレスの活用

これどこに入れるべきか悩みましたが、DevOpsに入れておきますw

GCP

  • CloudFunctions
  • Cloud Run

【GCP】えっ、Cloud Functionsだけじゃないの? - Qiita

AWS

  • AWS Lambda

データ分析基盤

分析基盤構築

  • データレイク
    • GCS
    • AWS S3など
  • データウェアハウス, データマート
    • BigQuery
    • Redshiftなど
  • データ分析
    • redash
  • エンジニア以外でこの数値を管理するか
    • スプレッドシート

データ分析のログ基盤

分析文化の醸成

  • ビジネス側がどのように分析できるようにするのか
  • SQLをビジネス側にどこまで普及させるのか
sanoyo
自衛隊からソフトウェアエンジニア
https://note.com/yokosano
engineerlife
技術力をベースに人生を謳歌する人たちのコミュニティです。
https://community.camp-fire.jp/projects/view/280040
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away