Classi開発者ブログ

教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。

開発メンバーの保守運用スキルを上げるため実施している朝当番制度の紹介

運用

こんにちは、開発支援部基盤インフラチームの kenryooo です。 Classiでは過去の高負荷によるアクセス障害での反省を踏まえ、エンジニア向けに保守運用スキルを高める施策として、朝当番という制度を運用しています。今回はその紹介をします。

目的

朝当番制度は、下記を目的に運用しています。

  • Classiのピークタイム(毎朝8:00 - 9:30)に問題が起きた場合、社内向けにスムーズな情報連携を行う
  • サービス品質の継続的な改善
    • パフォーマンスや監視内容に異常があった場合や、依存している外部接続システムやSaaSのメンテナンス情報などを担当チームへ共有する
  • 担当エンジニアの育成
    • Classiシステムの全体像の理解
    • 担当外のアプリケーション(リポジトリ)の理解
    • システム監視の入門(Datadog)
    • インシデントハンドリングの入門

背景と課題

朝当番制度は、下記の背景と課題感からスタートしています。

  • 上で述べた、先のアクセス障害時に朝のピークタイムに不安定な状態になることから、対応をスムーズに行うために朝当番担当を設けることになった
  • 人的コストを払って、エンジニアがただ張り付くだけではもったいないので育成の場にすることとした
  • Classiのアーキテクチャは、マイクロサービスではなく分断されたモノリス(複数のアプリケーションが同一のDBに依存している)であり、アプリケーション間でDBを介して密結合になっていることからシステム全体を理解しておく必要がある
  • もともとアラートにすぐ反応するのがシニアエンジニアに偏っており、対応できるエンジニアを育成するため成長機会を用意する必要があった
    • アラートにすぐ反応できない理由として、どう動いていいかわからない、対応できる自信がない、参加メンバーの多いチャンネルで発言することに抵抗がある、などがあった
  • ClassiではDatadogを活用しているが、開発者から「APMは使えるがシステムメトリクスの見方がわからない」という声があった
    • どのシステムメトリクスを見ればサービスに大きい影響を与える事象が起きていることがわかるか、が暗黙知になっていた

期待される役割

朝当番担当エンジニアには、ペア・モブでのオンボーディングを経て下記の役割が期待されることを伝えます。

  • アラートのディスパッチャーとして機能できること
    • アラートを担当チームへ適切に共有する
    • アラートの原因の調査や対応は、必ずしも行う必要はない
      • 複雑なシステム全体を理解し、対応まで行うのは現実的に難しい
  • 担当は基本的に一人
    • 当事者意識を向上させ最大限の効果を得るため
    • ただし、いつでもSREがサポートできる体制を確保している

期待される効果

朝当番を通して、下記の効果を期待しています。

  • アラートや外部接続システム、依存しているSaaSの異常に目を向けられるようになる
  • アラート対応への心理的障壁を下げて、まず反応できるようになることを目指す
    • アラート対応の速筋を鍛える
  • エスカレーション時に、所属しているチーム外の普段関わりにくいメンバーとやりとりをすることで、単純接触効果(ザイオンス効果)によるコミュニケーションの改善を狙う
    • リモートワーク下で減ったエンジニア間のゆるいコミュニケーションを補う

運用

朝当番メンバーの募集から参加までは、下記の内容をもとに実施しています。

  • メンバー募集
    • 挙手制
      • 家庭の都合(子供の送迎など)や、朝弱いタイプのメンバーを考慮
  • 担当期間
    • だいたい3ヶ月を目処
      • 本業に負担をかけすぎないことを意識
  • オンボーディング
    • 説明会
      • 責務や勤怠の説明
      • アラート通知、エラートラッカーの通知チャンネルの説明
      • Datadog のダッシュボードの説明
      • エスカレーションの方法
      • 参考書籍の紹介(入門 監視)
    • ハンズオン
      • 2〜3回、既存メンバーとペアまたはモブ形式で実施
      • システム構成や対応するダッシュボードの説明
      • 各アプリケーション(リポジトリ)と担当チームの説明
      • Datadogでの主要なメトリクスの解説
      • 既知のエラーの紹介
      • 終了時に記載しているレポートとサマリーの説明
        • リクエスト数の変化
        • ピークRAU(Real Time Active User)
        • alert/warning/error
        • 依存SaaSの稼働状況
        • 気づいたこと/やったこと
        • 申し送り

朝当番の振り返り

私の所属する基盤インフラチーム主催で、Infra Performance Working Groupという会を隔週で開催しています。 ユーザーの利用動向やシステムの稼働状況、アラートの対応状況、インフラコスト面の振り返りを行っており、その中で朝当番の振り返りも実施し改善につなげています。

結果

2020年9月からこの制度を運用を開始して、これまで19人のエンジニアが朝当番を経験しました。 制度開始以前は、数人のシニアエンジニアが中心になって行っていたアラート対応ですが、現在は新卒2年目くらいのエンジニアが中心となって問題の対応にあたることも多くなってきています。また、システムメトリクスも意識するプロダクト開発エンジニアが増えたことで、保守運用面での改善に自立的にリソースを割くことが増えたと感じています。過去に掲載したこれらの記事も、そうした影響を受けたものです。

結果として、基盤インフラチーム所属のSREは、本来やりたかったSREingに取り組める余裕が出てきました。

結び

エンジニア(開発者)の保守運用スキル向上についての取り組みについて紹介しました。 継続的に質の良いサービスを提供するためには、アラート対応、インシデント対応をできるメンバーを増やすことは重要ではないでしょうか。

Classiでは、SREプラクティスを活用してサービス基盤を改善していきたいエンジニアを絶賛募集しています！

© 2020 Classi Corp.