これはなに
- DORAコアモデルを読んでみて担当しているシステムはどうだろう？と考えてみたログ
- 何かしらNAに繋げていきたい
- 他人が読む前提で書いていません
Code Maintainability(コードの保守性)
- 組織的には戦略的投資としてエンジニア支援制度が結構ある
-
他の開発者が保守しているコードを容易に変更
- 影響範囲調査が大変
- ドキュメントが十分ではない
-
参考にするコード
- 真似してはいけないコードも一定ありそう
- コードの再利用
-
依存関係のバージョンアップ
- 上げた際の影響調査・テストが大変（マイナー程度ならOK）
Documentation quality(ドキュメントの質)
-
サービスのユースケース
- 業務フローだと逐一変わっていくのでどの粒度で書いていくべきか悩む
-
既存ドキュメント更新のガイドライン
- 既存ドキュメント自体に課題を感じているのでモチベが上がりづらい
- ドキュメントを書きすぎ or 簡潔ではないため工数懸念
-
ドキュメントの責任者
- 誰向けのドキュメントかを定義できていない
- ユーザ向けと開発向けで分けられたら良いかも
-
開発プロセスにドキュメント更新を含める
- 含めているが納得感があるかというと別問題
-
パフォーマンスレビューや評価にドキュメント作業を加える
- 一兵卒なので知らんけど出来ていない印象
Empowering teams to choose tools(チームにツール選択の権限を与えること)
-
ツール選択の自由
- 有償だと費用対効果は必要（当たり前）
Generative culture(生成的文化)
-
情報の円滑な流れ
- 上位レイヤーの話はなかなか入って来づらい印象
-
高い協力と信頼
- 開発 ⇔ 事業間はまだまだ改善余地がある
-
チーム間の橋渡し
- システム別ではなく事業別でのMTGなどは行っているがスムーズとはいかない
-
新しい解決策の受け入れ
- 既存に捉われない文化はあると感じる
Continuous delivery(継続的デリバリー)
- いつでもデプロイできる
-
品質やデプロイ成否のフィードバック
- エラー通知やデプロイ通知は来るがそういう話で合ってる？
-
CI・トランクベース開発・バージョン管理・自動テスト
- 細かく見れば改善ポイントはいっぱいありそう
Database change management(データベース変更管理)
-
データベースの変更をスクリプトとしてバージョン管理
- マイグレーションファイルで管理
-
データベースの変更をライフサイクル全体で可視化
- 変更管理はスプシ管理だから変えたいね
-
関係者全員と適切にコミュニケーション
- 網羅は出来ていないが最低限の通知くらい
- 関係者広すぎ問題が根本にある
Deployment automation(デプロイ自動化)
-
デプロイ自動化
- マージまでは少々手間があるがデプロイは自動
Flexible infrastructure(柔軟なインフラストラクチャ)
-
オンデマンドのセルフサービス
- 変更できるけどIaC反映が面倒？
- 幅広いネットワークアクセス
- リソースの共用
-
スピーディな拡張性
- スケールアップが多いのでスケールアウトも気軽に出来る状態にしたい
-
サービスが計測可能であること
- Observabilityツール導入
Loosely coupled teams(疎結合のチーム)
-
チームが他のサービスとの調整を必要としない
- 全然疎結合じゃ無いので厳しい
Streamlining change approval(変更承認の効率化)
-
変更管理プロセスが適切か
- 少ないような気はするがプロセスは早いので適切なのかな
Version control(バージョン管理)
-
バージョン管理システムを使用する
- コード・アプリ設定・システム設定・設定の反映はコード管理出来てる
Working in small batches(小さなバッチで作業)
-
作業単位を小さくする
- スクラム開発しているとPBIなるべく小さくしてMVPでリリースする意識はつく
Continuous integration(継続的インテグレーション)
- 定期的なチェックインと回帰テスト
Monitoring and observability(モニタリングとオブザーバビリティ)
-
モニタリングおよびオブザーバビリティツール
- SREチームに圧倒的感謝
Resilience engineering(レジリエンスエンジニアリング)
-
失敗を受け入れる
- 失敗を批判する文化も無いし、ポストモーテム実施して振り返ってる
-
継続的な改善
- これがポストモーテムかな
-
フォールトトレランス
- Writer落ちたら書き込みはダメかも
-
データ整合性
- 過去にDB移行で問題発生した
- オペレーションのログを残しているので何とか復旧出来た
-
負荷分散
- 繁忙期で多数のリクエストが来るとたまにCPUが張り付くがこれはアプリ側の問題
-
レプリケーション
- Writer・Readerで分かれている
-
自動リカバリ
- EC2なのでホストの自動復旧がされる
- EC2としてSLAは定義されていないが15分以内には復旧されるらしい
- EC2なのでホストの自動復旧がされる
Pervasive security(浸透したセキュリティ)
-
アプリケーションのセキュリティレビューを実施
- 社内向けシステムなのであまり意識できていない
-
情報セキュリティチームを設計およびデモプロセスに参加させる
- できていないなあ
-
事前承認されたセキュリティライブラリやパッケージを使用する
- 事前承認の仕組みはない
-
セキュリティ機能を自動テストスイートの一部としてテスト
- SAST／DAST的な話かな？話は上がってたけど出来てない
- 前職ではOWASP ZAPだった
Test data management(テストデータ管理)
-
テストスイートを実行するための十分なデータを確保
- 確認したい機能単位くらいでデータ作っているので作りすぎかもしれない
-
必要なデータをオンデマンドで取得できる
- データ作れるけどしんどい、もしくはコマンドでSTGのDump取得
-
テストデータの量は、可能な限り最小限に抑えることが重要
- だとすると作りすぎだな〜
Change lead time(変更リードタイム)
-
プロダクションに正常にデプロイされるまでの時間
- ここは以前改善して早くなったけど一般的に見たらどうなんだろう
Deployment frequency(デプロイ頻度)
-
頻繁にデプロイされるか
- 日に3回とかデプロイしてるけどリポジトリが大きすぎる面（密結合）もある
Change fail percentage(変更失敗率)
-
ホットフィックスやロールバックを必要とするデプロイの割合
- ここ最近意識できていないかも
Failed deployment recovery time(失敗デプロイの回復時間)
-
デプロイの失敗から回復するまでにかかる時間
- 割と早いはず
- 温度感によって復旧手段が2つ選べるのも良い点
Measurement coverage(測定カバレッジ)
-
SLIが設定されているか
- 話はあるけどまだだな〜
Measurement focus(測定フォーカス)
-
SLIはユーザーが経験するシステムの動作を反映しているか
- （泣）
Target optimization(目標の最適化)
-
SLOが適切に設定されているか
- 話はあるけどまだだな〜
Target compliance(目標達成度)
-
SLOは一貫して達成されているか
- （泣）
Commercial Performance(商業パフォーマンス)
- スキップ
Non-commercial performance(非商業パフォーマンス)
- スキップ
Job satisfaction(仕事満足度)
-
挑戦的で意味のある仕事に取り組むことから得られる充実感
- 実務知識があまり無い自分にとって挑戦的な事は多いかも
Productivity(生産性)
- 効果的に作業し、実験や反復作業を行い、学び続けてユーザー体験を絶えず向上
Reduced burnout(バーンアウトの軽減)
-
過労やストレスによって引き起こされる、身体的、精神的、または感情的な疲弊
- そこまでではない
Reduced rework(再作業の減少)
-
反応的かつ計画外の作業を指し、修復作業、緊急デプロイやパッチ適用など
- 運用作業のアプリ化を実施したのでかなり減った
- ある時期は毎日2〜3時間運用作業してた
まとめ
- 振り返って考えると出来ていないポイントが明確になっていいな〜
- 勢いで書いたので誤りもあるだろうし、チーム内のネタに昇華していきたい