Offers 技術組織の課題 a.k.a 誰か手伝ってリスト - SRE と Security編 | Offers Tech Blog
こんにちは、Offers を運営している株式会社 overflow CTO の 大谷旅人 です。
技術組織の課題開示しちゃうぞシリーズ - SRE & Security 編です。
引き続き、進行中または予定のプロジェクトを具体的な課題とともに開示し、技術組織としてどのような事に取り組んでいるかをお届けします。
SRE - リスクを受け入れた価値提供スピードの最大化
まず課題開示へ入る前に、弊社での SRE（Site Reliability Engineers）として求める役割について言及しておきます。
弊社の SRE は、以下のミッションを担う役割です。
- SLO/SLI 運用による事業価値毀損となるリスクモニタリング、その防止
- プロダクト開発サイクルへの組み込み
- 受け入れ基準の明確化と自動チェック
- リリースサイクル、運用負荷の軽減によるプロダクト変更速度の最大化
- ビルド、デプロイ速度改善
- 運用負荷モニタリング
- システム全体の IaC 管理
- 障害の早期発見、迅速に復旧可能な構成へのアップデート
- リリースタイミングとデプロイの分離
- セキュリティリスクへの対策、不正アクセスへの防御とデータ漏洩防止
プロダクトに存在するリスクを軽減しながら変更速度を最大化し、いかに事業価値向上へ貢献するかが求められます。
これらのミッションは小数のプロダクト成果が事業価値に大きく寄与する一方で、障害やセキュリティリスクが価値毀損やイメージ失墜に直結するスタートアップでは非常に重要な責務です。
Service Reliability Hierarchy / Part III. Practices より引用
Google が定義しているサービス信頼性の階層に照らし合わせると、私達の今の状態は甘めに見ても、Monitoring と Incident Response の間(ちょっとポストモーテム運用)です。
実践したいプラクティスは数多くありますが、理想と現実の差異を見極めつつプロダクト開発チームと協調して改善を進めようとしています。
という前置きの上で、以下の PJT・タスクを進行・計画中です。
SLO/SLI 運用の改善、可視化
SLO Dashboard
重要な機能に限り SLO/SLI を定め、管理・運用をしています。
エラーバジェットの減少を検知し、対応が必要な場合には JIRA 上へ起票を行い開発フローへ組み込むという運用です。
現在、以下の問題があります。
- 重要な機能をひと括りにモニタリングしていることから、緩い指標となってしまっている
- エラーバジェット減少検知後の対応判断を都度都度、人力で行っている
品質低下のモニタリングとしては改善の余地が大きく、ユーザストーリーベースに機能毎しきい値を設定し、定期的な見直しをリリースサイクルに合わせて行うことを計画しています。また、詳細に測定できるようログ自体のフォーマットも見直す必要が出てきています。
メトリクスやログデータの集約
サービス運用で監視すべきデータには、アプリケーションログ、バグトラッカー、APM、RUM、外形監視、監査ログ、管理画面等の操作履歴 etc がありますが
色々な SaaS を組み合わせて収集しているため、すべてを集約して見られておらずサイロ化してしまっています。
また上記のデータ以外ではリリースサイクルと運用負荷軽減の観点から、下記で挙げるようなプロダクト運用に関わるログデータも収集と集約することが理想であり、これらは都度都度他 SaaS を組み合わせて確認している状況です。
- デプロイ結果
- ブランチごとのデプロイ数
- デプロイ所要時間
- イメージ毎ビルド時間
- 開発チームへの問い合わせ
- 回数
- 対応時間
- 自動テスト結果
- カバレッジ率
- 所要時間
- 静的解析結果
- コードクオリティ
- コード量、モジュール量
- プルリクエスト結果
- 作成からマージ所用時間
このようなサイロ化してしまっているログやメトリクスデータを集約(Datadog へ)し、より適切に効果測定を行える環境を整えていっているところです。
オンコール体制とポストモーテム運用
インシデントが起きないサービスはないので、当然体制として整えておくべきですが、現状は私を含む一部のメンバーの経験と努力によってカバーされてしまっています。
インシデントが発生しても指揮者(Incident Commander)が臨機応変に指示出しとその後の調整をすることで何とかなっているレベルですが、管理機能の増加とともにバランスの取れた対応がしづらくなっているという課題が出てきています。
アラートの内容によってインシデント認定する基準の整理(深刻度レベル定義[1])、適切な人にのみ通知するオンコール体制の整備、対応時の行動指針のまとめ、ポストモーテムでの再発防止と整備はまだまだこれからですが、緊張感ある対応が少しでも安心して取り組めるよう努めています。
ビルド、デプロイ速度改善
イメージビルド速度、そしてそれに影響してデプロイ速度が非常に遅いです。遅さの原因は、
- 適切なビルドキャッシュが効いていない
- ライブラリインストールが遅い(bundler,yarn etc..)
- Assets コンパイルが遅い(webpack)
- 出来上がったイメージサイズがでかい & Push に時間かかる
- デプロイ後のスモークテストがこれもまた遅い
と地道な改善必要なものもあり、一気にとは行かずとも徐々に改善を進めています。
リリースタイミングとデプロイの分離
現状、リリースタイミングとデプロイが一緒になってしまっています。
その結果、何時何分にリリースすると決定した場合、デプロイをそれに合わせて実行する必要があるという問題があるだけでなく
feature ブランチの巨大化 -> レビュー時間かかる -> リリースサイズもデカくて動作確認も時間かかる -> 何か起こっても機能単位で即座に切り戻しできない
とリリースサイクル全体に悪影響が出ています。
Flipper or ConfigCat などのライブラリや SaaS で対応すべく現在計画中です。
Security - 日常的なリスク検知の整備と対応力の向上
プロダクト内外のセキュリティリスク可視化とその対応
プロダクト外では、AWS SecurityHub、GuardDuty、Config、CloudTrail によるリスク検知と証跡保存をしています。
プロダクト内では、Dependabot、snyk による検知をしています。
多くの指摘が日々検出されるため、優先度を判断しながら対応していますが、備えあれば憂いなしで他にも検知したい箇所はまだあります。
公開脆弱性に対する定期的な監視と評価
CVE 発行されるものの中でもプロダクトに関わるものは前項の検知によってカバーはできています。
運用観点だとそれで十分かと言うとそうではなく、某プラットフォームで発生した OAuth トークン流出や某 SFA で起きたデータ流出などいち早く検知し対応評価行うべきインシデントは多々あります。負担の少ない定期的な監視と評価フローを整備したいと考えています。
静的アプリケーションセキュリティテスト（SAST）
セキュリティチェックを開発フローにうまく組み込めていないという課題があります。
例えば、大きな機能をリリースする前に行う脆弱性診断の場合は一通りの開発が終了した頃、つまりリリーススケジュールの終盤で診断を実施します。このタイミングで大きな脆弱性が見つかった場合には少なからずスケジュールにも影響が出てしまうことが予想されます。
その分のバッファを確保して対応してはいますが、工数として予測できないものであることには変わらず、リリーススケジュールの後半に不確実性があるためマネジメント的に不安が残ります。
この課題を解消すべく、開発段階で事前チェックできるよう静的アプリケーションセキュリティテスト（SAST）の導入を進めています。
Brakeman、snyk、horusec、Shisho Cloud など様々なツールを効果測定(誤検知..)しつつ、実際の診断結果とも合わせて効果あるのか検証しています。
GameDay で 防災訓練
セキュリティインシデント時は、事前計画が対応速度を左右します。
計画整えたとしても突発事象の対応能力というのは実地で学ぶことも多く、チーム対応力を上げるには訓練が必要です。
そのため、ポストモーテム運用とインシデント体制がある程度整ってきた後、インシデント対応ゲームデー (シミュレーション)を実施予定です。
取り組みというか、行動指針が定着しているか確認する防災訓練イベントに近いです。
あとがき
以上、SRE & Security での課題と取り組みについてのご紹介でした。
攻めと守りのバランスをどう取り持つか、プロダクト開発にある課題を把握しきれているのか、etc.. 走りながら改善を繰り返していっています。
日々成長するプロダクトの維持と発展のために、課題と向き合い続けることに興味ある方、ぜひ一緒にやりましょう。
関連情報
もっと詳しく聞いてみたい！と思った方はぜひ カジュアル面談 しましょう。Podcast では弊社の技術チャレンジである「HR のデジタル化」についても語っています。
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion