1. 第１１章
基盤と環境を管理する

2. 11.1 導入
ü 最終目標
全てのテスト環境を本番環境と同様の方法で扱うこと
なぜなら、
１）環境面での問題を早期に発見できる
２）デプロイや設定の予行演習をして、リリース時のリスクを下げられる
ü 語句の定義
＜環境とは＞
アプリの動作や設定に必要な全てのリソースのこと
⇒ HW・NW、OS・ミドルウェア設定のこと
＜基盤（infrastructure）とは＞
組織内の全ての環境と、
環境をサポートするサービスのこと
DNS,F/W,ﾙｰﾀ,ﾊﾞｰｼﾞｮﾝ管理ﾘﾎﾟｼﾞﾄﾘ,ｽﾄﾚｰｼﾞ,監視,ﾒｰﾙｻｰﾊﾞなど
ü １１章の話題
デプロイメント用の環境を準備する手順
デプロイメント後の環境を管理するための手順
これらを実現するための包括的な手法

3. 11.1 導入
ü 包括的手法で基盤を管理するための原則
（１）基盤に要求される状態は、ﾊﾞｰｼﾞｮﾝ管理された設定で指定しなければ
ならない
（２）基盤は自動化（要求される状態に自動的に持ち込める）されなければ
ならない
※基盤のプロビジョニングも自動化プロセスに含めるべき
（３）基盤のリアルな状態を何らかの方法（監視など）で常に知っておかなけ
ればならない

4. 11.1 導入
ü デプロイ時のリスクを軽減させるために管理す
べき項目
（１）OSおよびその設定（本番、テスト環境両方）
（２）ミドルウェアスタックおよびその設定
（３）基盤管理用ソフトウェア（ﾊﾞｰｼﾞｮﾝ管理、監視システムなど）
（４）外部のインテグレーションポイント（外部システム）
（５）ネットワーク基盤
（６）アプリケーション開発チームと基盤管理チームの関係
特に（６）は、その他の項目の達成に効いてくるので、プロジェクト開始時から
協力関係を築くべきである
補足：（６）はDevOps運動の主な行動指針のひとつであり、DevOpsの狙いは、
アジャイル手法をシステム管理者やIT運用部隊の世界にもたらすことだ

5. 11.2 運用チームのニーズを理解する
ü プロジェクトの失敗のほとんどは人間的な問題であり、技術的
な問題ではない
・開発チームはできるだけ早くリリースすることを重視する
・運用チームはソフトウェアの安定性を重視する
⇒利害関係者の最終目標は同じで、「価値あるソフトウェアをリ
スクの低い方法でリリースすること」
＜筆者コメント＞
経験上、最善の方法は、できる限り頻繁にリリースすることである
（リリースごとの変更を小さくできる）
そのための継続的デリバリー
実際多くのケースで、リリースが数分で済むリスクの少ない作用になり、１日に何回もリリース
できるようになっている。
人間的な問題をなくすために、運用チームにとって重要な検討
事項を、知っておこう（次ページから）

6. 11.2 運用チームのニーズを理解する
11.2.1 文書化と監査
運用チームは、管理下の全環境の、あらゆる変更を文書化して
監査したい
＜なぜなら＞
・問題発生時の原因となる変更を見つけ出せる（主な理由）
・サーベン・オクスリー法（いわゆるSOX法）を遵守するため
＜手段として＞
変更管理手順がある ※もっとも重要な手順の一つ
・全環境のあらゆる変更を管理するために使われる手順
・変更には変更マネージャーの承認が必要
・リスクと変更による影響、およびリカバリー方法を説明する必要
・直前の説明では遅く、リリース計画に このプロセスを入れておくべき
★開発チームは変更管理の手続きを知り、それに従う責任がある

7. 11.2 運用チームのニーズを理解する
11.2.2 異常発生時の警告
運用チームは、管理するシステムに異常が発生した場合は警
告を発してほしい
＜なぜなら＞
ダウンタイムを最小化できるから
＜手段として＞
監視（いろいろある）
・何を監視するか、ログはどこに出力するか、異常を知らせる手段は何か
★開発チームは、（運用チームが考えている）監視の仕組みを
理解し、リリース計画に含める責任がある
・その他の要件と同様に扱い
・アプリの再起動や再デプロイ手順を用意する必要がある
・これらを最初のリリース時から考える必要がある
★重要なのは、アプリのリリースのサイクルに運用チームも組み
込むことだ

8. 11.2 運用チームのニーズを理解する
11.2.3 ITサービスの継続計画
運用チームが管理するサービスには、
・目標復旧ポイント（RPO）
・目標復旧時間（RTO）
が決められているため、
開発チームは、以下のことを行うべき
★業務継続性テストの一環として以下のテストを行うべき
・データのバックアップ・リカバリー、アーカイブなどのテスト
・任意のバージョンのアプリの取得やデプロイメント
★これらを業務継続性のテストの一環として行うべき
＜なぜなら＞
RPO,RTOを決める重要な要素になるから

9. 11.2 運用チームのニーズを理解する
11.2.4 運用チームが慣れている技術を使え
★開発チーム、運用チームの両方がデプロイシステムを理解して
おく必要がある
★デプロイ方法は、両チームで話し合ってきめるべき
★デプロイシステムを作り始める時点から運用チームも巻き込ん
でおくべき
★これらをリリース計画に含めておくべき
＜なぜなら＞
・運用チームは慣れていない技術を嫌う
・慣れていない技術だと、運用チームが理解できずリスクが増す
★デプロイシステムもアプリケーションと同じくらいに、テストやり
ファクタリングをするべき
★デプロイシステムそのもののバージョン管理もするべき

10. 11.3 基盤をモデリングし、管理する
★構成情報の準備や管理は自動化しなければならない
★可能であれば、HW,SWの調達時にデプロイや構成を自動化し
やすいかどうか考慮すべき
⇒調達時に考慮できない場合は、以下のことを考える
・基盤のプロビジョニングはどのように行うか
・基盤を構成するSWのデプロイや設定をどのように行うか
・プロビジョニングや設定が完了した基盤をどのように管理していくか
★基盤の作成や保守に必要なものはすべてバージョン管理下に
おく必要がある
＜少なくとも以下のもの＞
・OSのインストール定義（RedHatKickstartなど）
・データセンター自動化ツールの設定（Puppet、CfEngineなど）
・基盤の設定（DNSゾーンファイル、F/Wの設定など）
・基盤管理に使う全スクリプト

11. 11.3 基盤をモデリングし、管理する
★（前述の）バージョン管理下に置かれたファイルは、デプロイメ
ントパイプラインへの入力となる。
基盤変更時のデプロイメントパイプラインのジョブは、次の３つ
・影響を受ける全アプリが変更後の基盤でも動作することの確認を行う
（機能テスト、非機能テスト）
・変更内容をテスト環境、本番環境にプッシュすること
・デプロイメントテストを行い、新しい設定がデプロイできたことを確認する
★基盤を扱うときの重要な検討事項は、どの程度共有するかと
いうこと
（１）特定のアプリにのみ基盤設定が関係する場合
アプリのデプロイメントパイプラインに基盤設定のデプロイを含めるべき
（２）多数のアプリに基盤設定が関係する場合
アプリが特定の基盤設定（バージョン）に依存していることの管理が必要
個別のパイプラインを用意して基盤変更を実施したり、
複数のアプリに影響を及ぼす変更はデリバリープロセスを通して依存規則に従う
ようにする（？？）

12. 11.3 基盤をモデリングし、管理する
11.3.1 基盤へのアクセスを制御する
★既存システムの構成管理をうまくやるポイント３つ
（１）アクセス制御をして、変更をするには申請を要するようにする
（２）変更を基盤に適用するための自動化された手順を定義する
（３）基盤を監視し、問題を早期に検出する
本番環境には簡単にアクセスできないようにしておくことが重要
⇒未承認のアクセスは防がねばならない（内部からのアクセスも）
⇒問題が起こった時に、直接本番にログインして解決したくなる（ヒューリスティックな問題解決
割と正解な方法で時間が少なくて済む）
⇒ダメ：事態が悪化したときにだれがいつ何をやったのかの記憶が残らず、 問題の原因
を見つけることが不可能になる。
基盤が自動で作れないならば、まずはアクセス制御の実装をすべき（承認手続きを経
ないと変更ができなくする）
⇒不満の声は多くても、次のステップへ進むための必須条件
⇒これをやらないと基盤の自動化へ進めない（火消しに時間を費やすことになるから）
メンテナンス期間を作ればアクセス制御の実施がやりやすい
変更管理の手続きは重要だが、お役所的なものである必要はない
テスト環境への変更は本番よりも申請が通りやすくあるべきだが、手続きは本番と同様である
ことが重要

13. 11.4 ｻｰﾊﾞｰのﾌﾟﾛﾋﾞｼﾞｮﾆﾝｸﾞおよび設定を管理する
サーバーのプロビジョニングは職人芸になりがち、手動繰り返し
で問題が起こりやすい
⇒解決策として自動化
新しいマシンをデータセンターにおいて配線さえすれば、
電源投入からリモートで自動実行できる
（１）電源ON（IPMI、LOMなど）
※ネットワークBOOT設定にしておく
（２）OSのベースをPXEでインストール
このときにデータセンター管理ツール（Puppetなど）を
合わせてインストールしておく
（３）データセンター管理ツールでそれ以降の変更を自動化

14. 11.4 ｻｰﾊﾞｰのﾌﾟﾛﾋﾞｼﾞｮﾆﾝｸﾞおよび設定を管理する
11.4.1 サーバーのプロビジョニング
やり方として、
①完全な手動手順
おすすめしない
開発環境もこれはなし、本番に合わせなければならない
②自動化されたリモートインストール
後述
③仮想化
後述

15. 11.4 ｻｰﾊﾞｰのﾌﾟﾛﾋﾞｼﾞｮﾆﾝｸﾞおよび設定を管理する
11.4.1 サーバーのプロビジョニング
②自動化されたリモートインストール
新しい物理マシンを投入するときには最適
Unix系（というよりLinuxか）のOSベースイメージ配布
-­‐ PXE（Preboot
eXecuOon
Environment）
・BIOSでネットワークブートを指定したときに裏で動作
・プロトコルはDHCPに手を加えたもの
・ LinuxのdhcpdはPXEを提供できるものが入っている
・ TFTPサーバを用意する必要がある（ﾌﾞｰﾄｲﾒｰｼﾞ提供）
・ RedHatだとCobblerとか
・ RedHat,Debianにはシステム状態を保存して他のシステムの
・初期設定につかえる仕組みが用意されている
ベース配布後の設定は
-­‐ Kickstart（RedHat）、Preseed（Debian）、Jumpstart（Solaris）
・OSパッチ適用、起動デーモンの決定、基盤管理システムのエージェントインストールなど

16. 11.4 ｻｰﾊﾞｰのﾌﾟﾛﾋﾞｼﾞｮﾆﾝｸﾞおよび設定を管理する
11.4.1 サーバーのプロビジョニング
②自動化されたリモートインストール
Windowだと
-­‐ WDS（Windows
Deployment
Services）
・中ではPXEが動いている
・Windows2008EnterpriseEdiOonに搭載
・AD,DHCP,DNSが必要
・ブートイメージ（WinPE
WindowsPreinstallaOonEnvironment）と
インストールイメージの２つが必要
・Vista以降には２つのイメージが付属（BOOT.WIM、INSTALL.WIM）
・独自のインストールイメージを作成して使用することも可能
簡単なやり方
Hyper-­‐V使って、仮想マシン起動
必要な設定後、Sysprepを実行し、
ImageXを使ってドライブイメージをWIMファイルに変換
WDMに登録

17. 11.4 ｻｰﾊﾞｰのﾌﾟﾛﾋﾞｼﾞｮﾆﾝｸﾞおよび設定を管理する
11.4.2 進行中のサーバ管理
次にやることは、必要メンバー以外のログインをできなくする
・ 勝手に変更をできなくし、変更は自動化で全てやる
・何度やっても結果の構成は同じものができる
・システムが整えば、テスト環境や本番環境の全てが一元的に管理された構成管
理システムで扱えるようになる
⇒その結果として、
・全環境での一環性が保障できる
・既存と全く同じ環境を簡単に用意できる
・ハードウェア障害時に、以前と全く同じ状態の環境を完全に自動で用意できる
Windowの基盤管理ソリューション
SystemCenterConfiguraOonManager（SCCM）
⇒ADとWindowsSo[wareUpdateServicesを使ってOSの構成管理
仮想サーバも管理できる
アクセス制御はADに統合されている

18. 11.4 ｻｰﾊﾞｰのﾌﾟﾛﾋﾞｼﾞｮﾆﾝｸﾞおよび設定を管理する
11.4.2 進行中のサーバ管理
Unix系の基盤管理ソリューション
・アクセス制御はLDAP
・パッケージ？管理は、CfEngine、Puppet、Chef、Bcfg2、LCFG
※WindowsだとWPKGだけだが、これはUnixをサポートしない
Puppet、ChefにWindowsのサポートを追加する作業も行われていた
-­‐
Marione]eCollecOve（mcollecOve）は、すばらしい（らしい）
メッセージバスを使って大量のサーバへの問合せや管理を行う
プラグインを使って他のサービスをリモート制御できる
Puppet,Facterとのやりとりもできる
-­‐ それ以外に（強力で高価な商用ツール）
BladeLogic（BMC）、Tivoli（IBM）、OperaOonsCenterスイート（HP）
⇒これらのシステムの主な特徴は、冪等性（べきとうせい）
ツールに任せておけば、うまい具合に調整し続けてくれる

19. 11.4 ｻｰﾊﾞｰのﾌﾟﾛﾋﾞｼﾞｮﾆﾝｸﾞおよび設定を管理する
11.4.2 進行中のサーバ管理
Puppetについて詳しく
・オープンソース
・宣言的な外部DSLを用いて構成管理
・マスターサーバで構成情報を一元管理
・各サーバにはエージェントが動作し、マスターサーバから情報を取得し、
同期する
・構成を変更すると、マスターサーバは変更を全クライアントに展開し、時に
はクライアントサーバを再起動する
・初期状態がどんな状態でも変更が適用でき、同期される
おまけ
環境への変更をテスト駆動で行う（P353）
自動化によるプロビジョニング（P353)
Puppetの使い方具体例（P354～356）
Posaixのインストール例

20. 11.5 ミドルウェアの構成を管理する
ミドルウェアは、
・バイナリ、設定、データの３つで構成され、
・別々のライフサイクルがあるので独立して扱う
11.5.1 設定を管理する
・システムを動かすために変更が必要なものは全てバージョン管理下におく
・OSの標準インストールに含まれる場合
OSの管理と区別する必要はない
Puppetにただしパッケージがインストールされていることを確認させ
構成の更新はPuppetマスターにあるテンプレートで行う
このテンプレートをバージョン管理システムにチェックインする
・OSの標準インストールに含まれない場合
OSのパッケージ管理システムを使ってパッケージを作り、
共有パッケージサーバに配置する
・管理はプロジェクトの初期段階で済ませるべき
・ミドルウェアの設定情報はお気に入りのプログラムと同じくらい重要
・ミドルウェアの選定が可能であれば、設定をスクリプトで書く機能をサポートしている
ものがおすすめ（かっこいい管理ツールや標準規格準拠よりも）
・デプロイメントや設定を自動化できない製品は話にならない

21. 11.5 ミドルウェアの構成を管理する
11.5.2 製品を調査せよ
製品探しのスタートは、自動化された設定オプションがないのをはっきりさせること
他によい方法がないことがはっきりするまでは、先に進むな
11.5.3 ミドルウェアが状態をどのように扱うのかを調査せよ
ミドルウェアが設定の自動化に対応していない場合
裏にあるストレージ（おそらく設定情報のこと）をバージョン管理できないか調査
・XMLファイルなどで設定情報を保存している場合は、これをバージョン管理する
・バイナリーで保存している場合は、このバイナリーのバージョン管理を検討する
インストーラーごとﾊﾞｰｼﾞｮﾝ管理する
インストーラーを自作できるもの（RPM化など）
データベースに設定を格納するものは、バックアップ・リストアをﾊﾞｰｼﾞｮﾝ管理し自動化
設定の保存方法を調査してﾊﾞｰｼﾞｮﾝ管理、自動化できる方法を探そう
11.5.4 設定APIを探せ
製品のAPIを調査して、上手く利用する方法も検討しよう
11.5.5 よりよいテクノロジーを採用せよ
筆者の経験上、製品を解析し自前で自動化方法を探るよりは、
APIを探す、ベンダーに助けを求める、だめなら別製品を検討するほうがいい

22. 11.6 基盤サービスを管理する
基盤サービスが本番環境に影響をあたえることがある、F/Wのセッション保持期間と
アプリの設定のミスマッチとか
★いくつかアドバイス
・ネットワーク基盤の設定は全てバージョン管理しなければならない
自動で設定を配信し、自律活動させよう
バージョン管理した設定ファイルから変更が行われるようにしておこう
・ネットワーク監視システムを利用しよう（Nagios,OpenNMS,HPOperaOonsManager）
アプリで使う全てのルート、ポートを監視する
・ログと仲良くなる
レベル付け
予期しない接続断はWarning、 意図した切断はInfo、 接続開始はDebug
可能な限り、接続先情報を含める
・開発中のスモークテストで全接続をチェックし、接続の問題を洗い出す
・テスト環境をできるだけ本番環境に合わせる
完全な複製、障害時のバックアップ環境としても使える
★フォレンジックツール（ログや記録を調査し、起こったことを立証する証拠集め）
Wireshark,Tcpdump lsof（Unix）、Handle（Win）、TcpView（Sysinternalsスイート）

23. 11.6 基盤サービスを管理する
11.6.1 マルチホームシステム
システム耐性を高めるために、複数の分離されたNWを用意
通信負荷の分離、分散
⇒各サービスやアプリは必要なNICにだけバインドする
⇒アプリは、ListenするIPアドレスをデプロイ時に設定できるよう
にしておかなければならない
ネットワークのすべての設定は、一元管理し、監視しなければ
ならない

24. 11.7 仮想化
仮想化技術を使えば、紹介したテクニックの恩恵をさらに膨らませることがで
きる
・変更要求への迅速な対応（新しい環境の手配の時間短縮）
・整理統合（CIやテスト基盤の統合など）
・ハードウェアの標準化（上モノが要求するマシン仕様を仮想レイヤーが吸収してくれ
る）
・保守が容易なベースライン（イメージ一発でベースライン構築）
・チューニングまで行った環境を簡単に複製できる
・OSからアプリまで含めて、ある状態に戻すことが容易
・仮想サーバをベースライン環境とすれば、環境コピーの作成が容易になる
・デプロイメントの自動化のデモをさくっとできる（環境がすぐに用意できるし、すぐに削
除もできる）
・可用性のテスト自動化もやりやすい（クラスタ試験とか）
・一時的な環境が容易に準備できるので、テスト環境を増やして並列でテスト実行し時
間短縮が図れる

25. 11.7 仮想化
11.7.1 仮想環境を管理する
仮想化により、環境丸ごとをバージョン管理できるので、
・想定外の方法で出来上がった環境や、
同じ環境を一から作れなくても正常動作中のスナップショットを残しておけばよい
・管理を自動化できないソフトウェア
ソフトウェアの設定まで完了した状態をベースラインとしてバージョン管理しておけば
簡単に正常な状態へ戻せる
も扱えるバージョン管理が可能となる。

26. 11.7 仮想化
11.7.2 仮想環境とデプロイメントパイプライン
デプロイメントパイプラインの目的は、
「アプリの全変更をビルド・デプロイ・テストの自動化されたプ
ロセスで行い、リリースできるものかを検証すること」
仮想環境を用いると、アプリの検証を行ったベースライン環境そ
のものと合わせて、本番へデプロイできる
⇒アプリも基盤の設定も、キャパシティもすべてOKな環境
ただし、毎回これではディスク領域を食ってしまうので、
現実的には、
ベースライン： 基本的なOSイメージ＋最新パッチ＋ミドルウェア＋α
＋データセンター管理ツールのエージェント
あとは、ツールを使ってプロビジョニング手順を実行

27. 11.7 仮想化
11.7.3 仮想環境を使った、高度に並列化したテスト
・クライアント（ユーザのPC）などにインストールして使うソフトウェアの検証
⇒仮想環境だと、マルチプラットフォームの擬似環境が複数作れて検証し
やすい
・上記ケースに限らず、テスト環境を並列で用意しやすいことで、受入テスト
やキャパシティテストで重要となるフィードバックサイクルを短縮できる
・テスト環境をスケールアウト型で多く用意できることでテスト実行速度も向
上する
最終的に、テストのパフォーマンスに影響を及ぼすのは、
一番時間がかかるテストの実行時間と、
ハードウェア投資金額になる
⇒これもCIツールや、SeleniumGridなどを使えばシンプルに実現できる

28. 11.8 クラウドコンピューティング
クラウドコンピューティングは、アプリのクラウド化、プラット
フォームのクラウド化、基盤のクラウド化の３つに分類される
11.8.1 基盤のクラウド化
AWSなど
デリバリープロセスにおいてきわめて便利なツール
テスト環境を必要に応じて簡単に立ち上げられる
テストを並列実行するための環境が簡単に手に入る
※ただし、使えば使うほどロックインされてしまう。
クラウド移行を検討する人たちが考える重大な問題
（１）セキュリティ
・クラウド事業者もいろいろと対応している（F/W、VPN接続）が、
自前の環境とは勝手がちがうところが悩みどころ
・コンプライアンス
ダメというルールではなく、クラウドを想定していないルール
PCIDSS準拠しているクラウド業者もある
（２）サービスレベル
AWSもいろいろなパフォーマンスレベルのサービスを用意しているが、高性能サーバには及ばない？

29. 11.8 クラウドコンピューティング
11.8.2 プラットフォームのクラウド化
GoogleAppEngine、Force.comなど
メリット：
・原価構造やプロビジョニングという点で利益を得られる
・サービスプロバイダーが非機能要件の面倒をみてくれる
スケーラビリティ、可用性、ある程度のセキュリティ
・完全に標準化されたスタックをデプロイするので、設定や、テスト環境な
どの保守を気にする必要がなくなる
⇒ここまで説明してきたデプロイプロセスや構成管理のことを気にしな
くていいことになる。
デメリット：
・アプリに対する制約が厳しくなる（GoogleだとBigTableの実装だけとか）
・ベンダーロックイン問題

30. 11.8 クラウドコンピューティング
11.8.3 ひとつで何もかもを解決する必要はない
いろいろなサービスを組み合わせてシステムを構築してもかまわない
⇒そのためには、
・アプリケーションの設計時に混合環境でも動作するよう考慮が必要
・疎結合なアーキテクチャでの実装
11.8.4 クラウドコンピューティングに対する批判
※中身古いので割愛
クラウドが有用かどうかは、コストや節約費、その他の要素を
並べて検証してみるしかない

31. 11.9 基盤やアプリケーションを監視する
本番環境で起こっていることを見える化する理由
・リアルタイムなビジネスインテリジェンス
現在の収入や、収入源がわかればすばやいビジネス戦略が立てられる
・問題発生をすばやく運用チームに伝え、問題の根本原因を探り、修正する
・過去の履歴データは今後の計画を立てる上で重要
監視戦略時の考慮すべき点（４つ）
・アプリケーション、基盤に必要なデータを収集する仕組みを設置する
・データを格納し、あとで取り出し解析できるようにする
・ダッシュボードを作成し、集約データを運用チームや経営者にわかりやすく見せる
・重要なイベント発生をすぐに気づけるような通知の仕組み

32. 11.9 基盤やアプリケーションを監視する
11.9.1 データを収集する
・ハードウェアのデータ
電圧・温度、ファン回転数、機器の健康状態
・OSのデータ
リソースの使用状況、IO性能、プロセスの稼動状況
・ミドルウェアのデータ
メモリ・データベースのコネクションプールなどのリソース情報
接続数・応答時間など
・アプリのデータ
運用チームやビジネスユーザが気にする情報
例えば、取引成立数や価格、ユーザ層、動向
外部しすてむとの接続状況
アプリのバージョン番号や内部コンポーネントのバージョンなど
有名なフリーツール：Nagios,OpenNMS,Flapjack,Zenoss
商用ツール：IBM
Tivoli,HP
OperaOonsManager,BMC,CA,Splunk
Splunk：タイムスタンプを含む情報（ログやテキストデータ）を集めてインデクシング、検
索、ダッシュボード、通知

33. 11.9 基盤やアプリケーションを監視する
11.9.2 ログ出力
ユーザの使い方の理解や、問題の原因追跡に役立つ
ログ出力で気をつけるところ
・レベル分け（DEBUG、INFO、WARNING、・・・・）
詳細に情報取得したいときのDEBUGなど、表示できるようにしておこう
・ログファイルを見るのは運用チームであることを覚えておく
運用チームとともに作業をするとレベル分けが学びやすい
・記録内容：ログレベル、アプリ内のエラー発生箇所、エラーコードと説明
ログ出力機能は可監査性の一部で他の非機能要件と同様に重要な要件
運用チームと話し合い、欲しているものを要件に組み込む
ログの網羅性と可読性のトレードオフは重要な検討箇所
grepでほしい情報がまとめて見れるとか（１つのエラーを複数行にしないとか）

34. 11.9 基盤やアプリケーションを監視する
11.9.3 ダッシュボードを作成する
運用チームにとって、インシデントの有無を見やすくすることは重要
ノイズまみれにならないように事前に計画が必要
どのような信号を作るか
環境用、アプリ用、ビジネス用
信号の色と閾値を何にするか
赤・黄・青
参考（ナイガードの指針）
P３８３
グリーンはｘｘ
イエローはｘｘ
レッドはｘｘ

35. 11.9 基盤やアプリケーションを監視する
11.9.4 ふるまい駆動監視
運用者も基盤のふるまいの検証を行う自動テストを書く
Cucumber
Cucumber-­‐Nagios
Cucumberでテストを書き、Nagiosプラグイン用の書式で出力できる
⇒BDD（BehaviourDrivenDevelopment）形式のテストをCucumberで書いて、
結果をNagiosで監視できる
⇒この仕組みを使えば、アプリケーションのスモークテストも監視アプリに
組み込める

36. 11.10 まとめ
読者： 基盤を完全に自動化しろ？
読者： せっかく高い金を出してエンタープライズソフトウェアを買ったのに、付
属する管理ツールは使うな？
⇒ 筆者：そういうことだ！
★いつでもどこへでも完全に環境を再現できるようにするための
唯一の障害はコスト
⇒無料から高すぎるまでの間のどこかがおとしどころ
⇒対応のコストがかかっても長い目でみれば安くつく
★サードパーティーの製品を使うときの評価は、自動化した構成
管理にフィットするかを最優先で調べよう
★基盤管理の戦略はプロジェクト開始時点から考え、開発・運用
チームの利害関係者両方を巻き込むことが大切