DevOps時代のアーキテクチャ品質特性とプロセス品質概論

はじめに

　DevOpsという言葉は2008年に誕生した。その概念は2015年頃日本でも再注目され、これまでDevOpsに有用な技術や文化の変革について議論されてきた。このブログエントリでは、DevOpsがアーキテクチャとプロセスに与えた影響についておさらいしたのち、DevOpsに必要なアーキテクチャの品質特性とプロセス品質を一覧で示す。

DevOpsがアーキテクチャとプロセスに与えた影響

DevOpsの意義

　プロダクト開発では、要求分析からリリースまでのサイクルを回し顧客からフィードバックを素早く得ることで、プロダクトの品質を素早く継続的に向上することが重要だ。これを達成するため、「要求分析」「設計」「実装」「テスト」「リリース」などのバリューストリームマップに含まれる工程の生産性を改善し、リードタイムを短縮する手段を、DevOpsは提供する。下記の図で黄色の線で示された、要求分析からリリースまでのフローのリードタイムを改善するため、各工程の生産性を向上する。

DevOpsのバリューストリームマップとフィードバック

各工程の生産性改善のためのDevOpsの２つのアプローチ

　各工程の生産性を向上するため、DevOpsの技術的なプラクティス郡は２つの共通のアプローチをとる。それは

1. 各工程の手作業をソフトウェア化することで、それらを素早く、正確に、安全に、繰り返し実行可能になものにする。
2. （上記の1.の結果、）各工程のアウトプットについて、特に、問題があった場合にそれを素早く発見、修正するフィードバックループを作る。

　1.には、クラウドやInfrasutructure as Codeによるリリース作業や復旧作業のソフトウェア化、テスト自動化によるテスト実行作業のソフトウェア化などが含まれる。繰り返し実行する手順を自動実行できるようにしたり、システムの状態をコードで定義できるようにしたりすることで、各作業をソフトウェアとして管理できるようになる。

　2.には、テスト作業のソフトウェア化によって実装工程のアウトプットであるソースコードの問題を素早くフィードバックするCI/CDや、リリース作業のソフトウェア化によってリリース工程のアウトプットである本番環境の問題を素早くフィードバックするカナリヤリリースなどが含まれる。上記の図に青の線でこのフィードバックループを示す。

手作業のソフトウェア化とフィードバックループが意味するもの

　DevOpsのプラクティスによる手作業のソフトウェア化とそれによるフィードバックループは、すなわちDevOpsがシステムのアーキテクチャーと開発のプロセスに織り合わさって変化をもたらしていることを意味する。

　システムのアーキテクチャ面では、プロダクトの外部品質だけでなく、ソースコードを容易に変更したり、テストやリリース作業を容易にソフトウェア化するための内部品質の重要性が増している。テストやリリース作業を容易にソフトウェ化することが可能なように、プロダクトを設計する必要がある。

　また、ソフトウェア化するテストやリリースなどの手作業は、それそのものがソフトウェアでありプロセスでもある。そのため、それぞれの作業をについてソフトウェア面の品質特性と、プロセスの品質を組み合わせて考慮する必要がある。

　次の章から、DevOpsで特に重要なアーキテクチャの品質特性とプロセス品質を一覧する。

DevOpsのアーキテクチャ品質特性

プロダクトの変更容易性（実装作業）にまつわる品質特性

ソースコードの保守性	プロダクトのソースコードは素早くなんども変更可能か？コードの可読性や、単一責任などのクラス設計は適切か？
サービスやコンポーネントの独立性(*1)	１つのサービスやリリースなどの変更を入れる際に、他のサービスやコンポーネントにも変更を入れる必要があるか？変更の影響は限定されているか？
データの結果整合性(*2)	複数のサービス間で共有されるデータには、どの程度の整合性が求められるか？結果整合性の場合、上記の独立性は担保できるか？

テスト作業のソフトウェア化にまつわる品質特性

テスト結果の取得容易性	システムへのリクエストやアクションの結果を期待結果として定義できるか？また、その結果をシステムから容易に取得可能か？
テスト結果判定の自動化容易性	テストの期待結果をコンピュータにも理解できる形で定義可能か？またテストの合否をコンピュータが判定可能か？
テスト実行の並行性	複数のテストケースを並行して実行することは可能か？テストケースやテストデータは独立か？
テスト実行の冪等性	テストケースは繰り返し実行しても同じ結果が保証されるか？テストの事前準備や事後操作がテストデータの冪等性を担保するか？
自動テストの結果の信頼性	テストのカバレッジは十分か？テスト環境は適切か？テスト実行ごとに異なる結果を返すFlaky Testの数は最小化されていか？
自動テストのレポートとログの判断容易性	テストレポートとログから素早くテスト結果を判断できるか？テスト失敗時に素早く調査可能か？

リリース作業のソフトウェア化にまつわる品質特性

サービスやコンポーネントの独立性	(*1)と同じ
複数バージョンの共存性	本番環境などで、複数のバージョンが共存可能か？バージョン間でI/Fなどの互換性はあるか？
リリース・リカバリ手順の冪等性(*2)	リリース手順は繰り返し実行しても同じ結果を保証するか？
インフラの廃棄可能性(*3)	既存のインフラを廃棄しても、同じものを再現可能か？
リリース影響の制御容易性	リリースの影響をフィーチャーやユーザーセグメントなどの単位で制御可能か？ リリースの影響範囲を段階的に制御可能か？
リリースやリカバリ結果の判断容易性(*4)	リリースの合否の判断は容易に可能か？　判断に必要なシステムログやアプリケーションログは容易に取得可能か？

システムの復旧や運用作業にまつわる品質特性

システムの耐障害許容性	単一のシステムの障害が、他のシステムに影響を及ぼしたり、新たな障害を引き起こしたりしないか？
リリース・リカバリ手順の冪等性(*2)	(*2)と同じ
インフラの廃棄可能性(*3)	(*3)と同じ
システムのスケーラビリティ	アプリケーションやデータベースは独立性が担保されており、容易にスケールアウトすることが可能か？
リリースやリカバリ結果の判断容易性(*4)	(*4)と同じ
エラーログの判断容易性	エラーログから障害は素早く検知可能か？影響調査や原因調査を素早く行うのに対し、妥当なログが得られるか？

DevOpsのプロセス品質

実装工程の品質

ソースコード品質	実装工程の成果物であるソースコードの、コード行数、複雑度、コピペコードの割合などの技術的負債の量
実装工程で作り込まれた不具合数	実装工程で作り込まれた不具合数（テスト工程、リリース工程で発見した不具合数と市場に流出した不具合の総数）

テスト工程の品質

自動テストの品質	テスト工程の成果物である自動テストの、テストケース数、カバレッジ、実行頻度およびFlaky Testの割合
自動テストの所要時間	テスト準備、実行、およびテスト結果の調査にかかる時間
テスト工程での不具合発見率	不具合の総数に対する、テスト工程で見つかった不具合の割合
テスト工程での不具合修正時間	実装とテストの工程やチームをまたぐ、テストによる不具合の発見から修正、再テストによる修正確認までの時間

リリース工程の品質

リリースの品質	リリース工程の成果物である自動リリースの、デプロイ頻度、リリース成功率および失敗時の影響制御割合
リリースの所要時間	リリース準備、リリース作業、および事後確認にかかる時間
リリース工程での不具合発見率	不具合の総数に対する、カナリヤリリースで見つかった不具合の割合
リリース工程での不具合修正時間	実装、テストとリリースの工程やチームをまたぐ、リリースによる不具合の発見から修正、再テストによる修正確認および再リリースまでの時間
障害復旧時間	開発と運用チームをまたぐ、障害発生から検知、調査と不具合の修正やホットフィックスのリリースまでの、障害発生からリカバリするまでの時間
運用・保守作業時間	インフラチームとDBチームなど、複数のチームをまたぐ運用・保守の作業時間

 まとめ

　DevOpsがアーキテクチャとプロセスに与えた影響を概説し、DevOpsで重要なアーキテクチャの品質特性を工程・作業ごとに一覧で示した。DevOpsのプラクティスを通して生産性を改善するには、これらのアーキテクチャの品質特性とプロセス品質を考慮し、アーキテクチャとプロセス両面から改善活動を行うことが重要だ。