# 20. DevOps
________________________________________
SRE サイトリライアビリティエンジニアリング  
https://sre.google/sre-book/table-of-contents/

SRE サイトリライアビリティエンジニアリング（書籍版）  
https://www.oreilly.co.jp/books/9784873117911/

The DevOps ハンドブック 理論・原則・実践のすべて  
https://bookplus.nikkei.com/atcl/catalog/17/P85480/

________________________________________
## 1. 用語と考え方
________________________________________
### 1.1. DevOpsの用語と考え方

用語集


用語                          |意味
------------------------------|---------------------------------------------------
Continuous Integration        |CI。継続的インテグレーション
Continuous Delivery&Deployment|CD。継続的納品&デプロイ
Site Reliability Engineering  |SRE。サイトの信頼性に関する理論や技術
Release Engineering           |リリースエンジニアリング。SREの主分野
Toyota Kata                   |トヨタの型。DevOpsのメンタル面の1つ
Toyota Production System      |TPS。体系化されたものはリーン開発。DevOpsのメンタル面の1つ
Lean Software Development     |リーン開発のソフトウェア版。DevOpsのメンタル面の1つ
Theory of Constraints         |TOC。制約条件理論。DevOpsのメンタル面の1つ
Agile Software Development    |アジャイルソフトウェア開発。DevOpsのメンタル面の1つ
Infrastructure as Code        |IaC。環境のブラックボックス化を撲滅したい

-

DevOpsって何？

```text
トヨタ型 + リーンソフトウェア開発の考え方 + infrastructure as code
を基本に、開発チーム・運用チーム・顧客フィードバックの範囲に拡張して適用した開発手法・組織運営手法
```

DevOpsのメンタル面要約

- 1日1回本番デプロイをやろうと思えばできるようにしたい（組織面も、技術面も）
- 日々改善したい。漸近的にkaizenしたい（=トヨタ型）
- リードタイムの最小化が最も大切だ。小さなバッチサイズ（意味は後述）を可能にしたい（=リーン開発/TPS）
    - リードタイムは、ある開発が始まってから実際にリリースされるまでの待機を含む時間を指す
    - バッチサイズは、最小ロット数のような概念。ソフトウェア開発ならリリース時の機能数など
- 各ステップのリードタイムが長くなっている原因の改善が重要だ。全体が改善するはずだ（TOC）
- 2週間～3か月以内でプロジェクトサイクルを回そう（=アジャイル）

DevOpsのメンタル面の言いかえ

1. 開発→運用→顧客の納品を高速にせよ。仕事を可視化しバッチサイズを小さくし不良品をなくせ
2. 顧客→運用→開発の応答を高速にせよ。要望や問題発生は即座に開発タスクになるようにせよ
3. 小規模なリスクと実験の繰り返しが可能なkaizenが習慣化された組織体制にせよ

DevOpsに必要なアプローチ

1. 作業の可視化
    - タスクを付箋にしてホワイトボードに張り付けろ。Redmineでもいいけど同等の効果を期待する（IT版カンバン方式）
2. 仕掛かりの制限（各ステップのタスクキュー長の制限）
    - キュー長を制限すると、待ちが発生するようになる
    - 待ちの原因と改善案を探すのが、DevOpsのアプローチ
        - 別の仕事を始めてはいけない
        - 個人レベルのマルチタスク問題の改善など
        - 「始めることをやめよ、終えることを始めよ」
3. バッチサイズの縮小（featuresブランチの細分化）
4. 受け渡しの数の削減（部署や工程分担を細分化しすぎない）
5. 絶えず制約条件を見つけ出して尊重する。（ボトルネックを正しく認識せよ）
6. バリューストリームからムダと苦痛を取り除く

雑学

- トヨタ第一パラドックス：専門職+大量量産ではなく、トヨタ型+TPSだったこと
- トヨタ第二パラドックス：トヨタ自身は市場指向型組織ではなく職能指向型組織だったこと
- Conwayの法則：ソフトウェアの設計はその開発組織の組織構造の模倣になる

________________________________________
### 1.2. 補足：典型的な管理ツール

チケット（Redmine、Backlog）

- 部署間やベンダー顧客間など、長期間滞留したり監査用の証跡が必要な時はこれ
- 重厚で面倒かつ視認性が悪いが、コメントによるやり取りや完了チケットとして残るなど、証跡が残る
- エンジニアチーム内のタスク管理には向かない

IT版カンバン（≒ホワイトボード付箋をTodo/Doing/Doneで管理し、Doing数の制限をかけたもの）

- すぐに取り掛かることができて完了が可能なタスク（典型的には実装～単体テスト範囲）
-- あるいは、管理者が十分にメンバーを信頼できる時
-- あるいは、細かい作業を口頭のみやチャットのみ行っており、作業漏れ等のミスが出てきた時
- WFやスプリントが面倒になった、十分な開発速度がすでに出ているチームのチーム内タスクで推奨

スプレッドシートによるTodoリスト（付箋ではなく表で管理）

- IT版カンバンと概ね同じ目的。どちらを採用するかは好み
- 主に追加開発や不具合対応のフェーズに入った後はこちらが便利
- 典型的な項目は以下
-- 番号
-- 機能ID
-- 機能名
-- 指摘記入日
-- ステータス：保留、対応完了、差戻、対応不要、確認完了
-- 関連チケット
-- 指摘者
-- 指摘事項
-- 対応者
-- 対応結果特記事項
-- 対応済(設計書)：不要、済
-- 対応済(ソース)：不要、済
- ステータスが対応不要であるか、確認完了かつ対応済(設計書)と対応済(ソース)にステータスが入っているものを非表示

チャットツール（Slack、Chatwork、Google Chat（2022年9月以降、Slackライクな使い方が可能になった）、Skypeなど）

- 例えばベンダー顧客間におけるRedmineは、アプリケーション変更管理、QA、障害管理の3つ
-- QAは実質的には品質保証とQ&Aのダブルミーニング。実質雑多な質問、保守範囲作業依頼
- 軽い相談や質問は、わざわざRedmineでチケット化せず、企業間で何らかのチャットツールを導入しやり取りしたほうが良い
-- 性質上、お互いの企業が社内チャットに使用していないツールを使うか、背景色を明示的に分けるなどすると、認知負荷が低い
- チャットツールには「調査に着手」「対応中」「未解決」「○○（ベンダー名）済」アイコンを追加しておくとよい
-- 「未解決」が長引くようなら、RedmineでQAチケット化する

________________________________________
## 2. 技術的な実践
________________________________________
### 2.1. デプロイパイプラインの基礎を作る

前提や目標

- バージョン管理システム
- ステージング環境あるいはUAT環境の常設
    - 開発の完成の定義をステージングで動いた、とする
- 容易な環境構築、環境構築手順の明確化
- devとmasterの差異を少なく保つ。開発規模に合わせたシンプルなgit運用
- 環境構築情報こそバージョン管理せよ。infrastructure as code
    - ブラックボックス環境（手作業で設定しさらに再現困難な手作業変更された環境）の撲滅
    - 修理より再構築を簡単にせよ
        - サーバはペットではない、家畜だ（病気になったら殺して作り直せ）
- 資料も、データも、ソースコードもバージョン管理してDRY

________________________________________
### 2.2. 高速で信頼性の高い自動テストを実現する

自動テストはリリース後も継続的な開発を続けるなら、後追いでもよいのでつけるとよい

例：Google

- 1日当たりのコミット数 = 4万
- 1日当たりのビルド回数 = 5万。平日は9万回を超えることもある
- 自動テストスイートが12万本
- 毎日実行されているテストケースは7500万
- テスト、CI、リリースエンジニアリングの整備に関わるエンジニアが100人以上

テストの種類

- xUnit Testing
- 自動受入テスト/リグレッションテスト（ITbの業務シナリオテスト相当）
- 自動インテグレーションテスト（ITbの実物の外部サービス連携テスト相当）
- マニュアルテスト

________________________________________
### 2.3. 継続的なインテグレーションの実現と実践

- 自動テストは高レベルなCIでは必要になってくる
- 分岐製品ごとのブランチより、単一のブランチとパラメータ化

________________________________________
### 2.4. 自動化とローリスク・リリースの実現

自動デプロイの考え方

- 手動デプロイは苦痛（ムダ）であり、改善が必要である
- 少なくとも、デプロイが複雑であれば手順化されている必要がある（手順化は自動化の前段階である）

デプロイプロセスの自動化要素

1. デプロイに適した形でコードをパッケージングする
2. 構成/設定前の仮想マシンイメージやコンテナを作る
3. ミドルウェアのデプロイ、構成/設定を自動化する
4. 本番サーバーにパッケージやファイルをコピーする
5. サーバー、アプリケーション、サービスを再起動する
6. テンプレートから設定ファイルを生成する
7. システムが動作し、正しく構成/設定されていることを確かめるために自動スモークテスト（※）を実行する
8. テストプロシージャを実行する
9. データベースのマイグレーションをスクリプト化・自動化する

※ WebサーバやDB、その他要素が接続可能なことを確認する簡易テスト

デプロイパイプラインの要件

1. すべての環境に同じようにデプロイする
2. デプロイのスモークテスト（※）を行う
3. 統一的な環境を確実に維持する（手動調整の禁止）

デプロイとリリースの分離の基本的な思想

- DB変更のないLB配下のリリースなら、ノードを切断して事前にデプロイを全て済ませてからリリース
- 事前に特定の1%の顧客だけに機能を公開して影響度を測る、ダークローンチ

デプロイの具体的なパターン。青緑パターン2種

- 1. シンプル
    - 本番環境をまるまる2つ用意して、片方をステージングとして利用する
    - DBも複数。リリース時には旧環境を読み取り専用に制限してDBバックアップ後、新DBに復元する
- 2. DBとアプリケーションの分離
    - 本番環境をまるまる2つ用意する
    - DBは単一。前提としてスキーマ変更は追加のみサポートするような開発とする（列削除などは許可しない）
    - アプリケーション側は、DBのバージョンが直近のどちらのバージョンでも動くように開発・テストしていく
    - 先にまず旧アプリケーションのままDBを更新し、その後に新アプリケーションをリリースする（順次で良い）
    - 新環境と旧アプリケーションは並行稼働し、利用者は好きな方を利用する
    - 適当なタイミングで、旧アプリケーションを停止する

DevOpsの双方の歩み寄り

```text
・「デプロイプロセスの自動化要素」の単純化・高速化、という観点でアーキテクチャ設計を見直す
・日々の社内共有環境のデプロイと本番のデプロイはどちらも運用チームに任せてみる
・クラウド上のLB・WAF・RDS等も同等のステージング環境の用意とデプロイも頻繁に行うようにする
・ステージングでのDBテストでは、実際に100GBのデータを投入して検証してみる
・トラフィック量なども、本番を想定して検証してみる
```

________________________________________
### 2.5. ローリスクリリースのアーキテクチャ

- 締め殺しアプリケーションパターン