1. Operation Lab
運用設計ラボ
ドキュメントを書こう!
運用自動化時代のドキュメンテーション
運用設計ラボ合同会社
シニアアーキテクト 波田野 裕一
2014-07-26
JAWS-UG Chiba 第4回勉強会

2. Operation Lab
運用設計ラボ
✦ 初体験は2010年頃(EC2)
✦ 本格的に触り始めたのは昨年12月
✦ 今年2月にAPN(パートナ)に登録
Business Specialist / Technical Specialist
自己紹介
波田野 裕一 (HATANO Hirokazu)
運用設計ラボ合同会社 シニアアーキテクト
AWS歴
好きなAWS: AWS CLI

3. Operation Lab
運用設計ラボ
自己紹介
✦ Sphinx Users-jp 会長 (2014年度)
✦ 日本UNIXユーザ会(jus) 幹事 (副会長)
✦ IPv6普及・高度化推進協議会 (サブWG 部会長 共同)
✦ Internet Week プログラム委員
✦ Internet Conference 実行委員
✦ BSD / OSS / JANOG
波田野 裕一 (HATANO Hirokazu)
運用設計ラボ合同会社 シニアアーキテクト
‣ ADSLキャリアで開通業務、ATM運用、ISP運用および障害監視を担当
‣ SIerで公共系サービスのサーバ保守
‣ ASP でミドルウェアおよび障害監視システムの設計構築運用
‣ 運用設計ラボを設立。主にドキュメンテーション活動。
業務歴
参加コミュニティ
「レガシー運用」に詳しい人

4. 「運用」のたてつけがおかしい
人によって概念が異なる。
本当(?)の「運用」に対する予算がない
ドキュメントがない
属人的だ
障害が起きても、実は初動手順はない
設計が悪くてもフィードバックできない
出典: JANOG24 (2009/07)「障害監視&システム運用を語ろう ∼ 障害監視フレームワークと運用方法論研究∼」

5. じゃ、運用ってなんだ?
運用の妙は一心に存す
うまく機能を働かせ用いること、活用。
そのもののもつ機能を生かして用いるこ
と。活用。
(広辞苑 第六版)
(宋史岳飛伝、14世紀中葉)
(大辞泉)
出典: JANOG24 (2009/07)「障害監視&システム運用を語ろう ∼ 障害監視フレームワークと運用方法論研究∼」

6. Operation Lab
運用設計ラボ
「運用はいつも忙しそうだが
何をやっているのかよくわからない」
とおっしゃる方がいます、が
本日のお題
「やっている方もよくわかってないんですよ」
と、までは言えませんが、
なんだかうまく説明できない。

7. Operation Lab
運用設計ラボ
運用ドキュメントの位置付け
✓ 運用ドキュメントと運用業務は表裏一体の関係にある。!
✓ ツールやスキルに対する的確な要求は、客観的なドキュメントがあってはじめて
実現可能となる。!
✓ ドキュメントのない業務は、存在しないことに近く、客観評価されない。!
✓ 事業の継続性は、ドキュメントがあってこそ確保可能となる。
ドキュメントのない作業は、客観的には
「業務が存在しない」に等しい
(Internet Week 2009 「運用方法論」より)
「運用は忙しそうにしているけど、何やっているのかわからない」と言われてしまう。

8. Operation Lab
運用設計ラボ
ミスが多発
異動で混乱
運用でカバー
運用ドキュメントが無いと…

9. Operation Lab
運用設計ラボ
業務の客観評価
運用ドキュメントが有ると…
反復性・再現性
適切な自動化
365日24時間稼動が必要なサービスにおいて

10. Operation Lab
運用設計ラボ
「自分達のやっていることの安定化&永続化のために」
ドキュメントが実現するもの
脱属人化
客観化
整理
「記録」はドキュメント の本質的な基礎機能記録
「書く」という作業により「整理」されていく
「有形の成果物」となることで「客観化」されていく
時と空間を超えて知見が共有されていく
Level.0
Level.1
Level.2
Level.3
自動化はココ
「自分達のやっていることを知る&改善するために」
「自分達のやっていることの説明&(自己・他者)評価のために」
出典: Internet Week 2011 「運用ドキュメント2011 ∼手軽にスピーディに継続的に保守するためのツール入門」 Part-1
手順書はココ

11. Operation Lab
運用設計ラボ
「自動化」について注意したいこと
自動化は、「客観化の結果」であって「目的」ではない。
「自分達のやっていることの安定化&永続化のために」、目的:
手段: 自動 「客観化(構造化)された業務の一部」を自動化する。
「目的と手段がひっくりかえる」ことは、よくある
「自動化が目的」の弊害
• 「自動化された業務」の保守が属人化する。
• 「自動化された業務」の仕様が不明になり、業務プロセスが硬直化する。
• 「自動化された業務」でトラブルが発生すると、手動ではリカバリができ
ない。(手順がわからない)
参考 「自動化」について

12. Operation Lab
運用設計ラボ
DevとOps「目的」と「手段」の比重 (自動化へのスタンス)
大量生産
工場型モデル
研究所型
モデル
受注生産
工場型モデル
Dev
Ops 目的 手段
目的 手段
目的 手段
エンジニア
リサーチャ
マイスター
オンプレミス時代の運用は「家内制手工業」に近い
クラウド時代の運用
参考 「自動化」について

13. Operation Lab
運用設計ラボ
運用ドキュメントが無い「工場」
インターネット運用は「安く、手間をかけず」が特徴で、運用設計と
ドキュメンテーションがないがしろにされてきた。(企業の大小、社歴
の長さを問わず)
今後は、リモートワーク拡大、メンバーの流動性向上、サービスのライ
フサイクル短期化(扱うサービス数の爆発的拡大)により、アンドキュメン
テッド設計&運用は致命的な「知識のロスト」を生む可能性が
生産ラインを最初に稼動させ、後から金型を作るようなもの
「品質」定義の無いアウトプット、事故多発可能性…
参考
大量生産
工場型モデルOps
クラウド時代の運用

14. Operation Lab
運用設計ラボ
「クラウド時代の運用」キーワード
「問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのがエンジニアの仕事です」
@yoshiori
構造化
ここでは「エンジニアリング(工学)の実践」
に近い意味で使います。
工学では何らかの構造物・構造体を作ること
が不可避なためです。
http://d.hatena.ne.jp/Yoshiori/20120217/1329491437
参考 「構造化」について
客観性、再現性、定量評価

15. Operation Lab
運用設計ラボ
サービス
工程
Step1
開
始
サービス
工程
Step2
サービス
工程
Step3
サービス
工程
Step4
サービス
工程
Step5
提
供
前処理inbound 本作業 後処理 outboundinbound outbound
Quality
Cost
Delivery
データ(QCD)に語らせるのがエンジニアリング
時間という物性
金額という物性
品質という価値観
運用プロセスの構造化
参考 「構造化」について
客観性、再現性、定量評価

16. Operation Lab
運用設計ラボ
顧客・外部サービス
Inbound Queue Outbound の繰り返し
outboundinbound
outboundinbound
外部支援組織
inbound
inbound
運用メンバー
outboundinbound
内部協調/支援組織
inbound
outbound
リクエストデリバリ
デリバリ
デリバリ
デリバリ
リクエスト
リクエストリクエスト
運用現場
窓口 フロントエンド
バックエンド
outbound
outbound
EndPoint
API
疎結合
サービス運用全体の流れ (運用プロセスの疎結合集合)
参考 「構造化」について
SWF
DataPipeline
SQS

17. Operation Lab
運用設計ラボ
「自分達のやっていることの安定化&永続化のために」
運用ドキュメントが実現するもの (クラウド時代)
脱属人化
客観化
整理
「記録」はドキュメント の本質的な基礎機能記録
「書く」という作業により「整理」されていく
「有形の成果物」となることで「客観化」されていく
時と空間を超えて知見が共有されていく
Level.0
Level.1
Level.2
Level.3
自動化
「自分達のやっていることを知る&改善するために」
「自分達のやっていることの説明&(自己・他者)評価のために」
出典: Internet Week 2011 「運用ドキュメント2011 ∼手軽にスピーディに継続的に保守するためのツール入門」 Part-1
構造化
構造化(粗)

18. Operation Lab
運用設計ラボ
脱属人化
客観化
整理
Level.1
Level.2
Level.3
How
Why
設計
実装
CloudFormation
OpsWorks(Chef)AMI
ドキュメンテーション
構造化された設計+ドキュメンテーション
人のための構造化
両者を結合
構造化メモ
精緻な構造化
エンジニアリング
システムのための構造化
+システムによる構造化
目的

19. Operation Lab
運用設計ラボ
まとめ: クラウド時代の運用ドキュメンテーション
• WhatやHowはコード(Infrastructure As Code)に残るが、Whyは人
が自らドキュメントに書かなければ残らない。
• クラウド時代になって、オンプレミスと比較してあらゆる制約が減
少。制約が無い中で「なぜそうしたか(Why)」を残す重要性が増加。
• 人(Why)とシステム(What/How)が分担してドキュメントを書く時
代。
How + Why = KnowHow
実装 設計 運用現場の資産

20. Operation Lab
運用設計ラボ
おまけ: ドキュメント書けないなら
ガイドラインやベストプラクティスに極力準拠する。
• 聞かれたら、ガイドラインやベストプラクティスを差し出せばOK。
• 差分だけ書けば良くなる(はず。)
AWSには潤沢すぎるドキュメントがある。
全部読んで、全部準拠すればOK
ある意味、運用ドキュメントのアウトソーシング

21. Operation Lab
運用設計ラボ
運用ドキュメントについて語ると…

22. Operation Lab
運用設計ラボ
キリがないので、詳細は…

23. Operation Lab
運用設計ラボ
ドキュメンテーションツールの一例

24. Operation Lab
運用設計ラボ
ところで AWS Unified CLI つかってますか?
ドキュメントテーションツールの一例

25. Operation Lab
運用設計ラボ
• テキストメモに近い構造化記法 (reSTructured Text)
• 気が向いたときに、気が向いた程度に構造化が可能
• 1ソース マルチアウトプット
• HTML/PDF/ePub/man/text/XML/JSON etc…
• 一度書いたものは、ひたすら使いまわしが可能。
• 強力なディレクティブ
• 構成変更に対して自動追随可能
• 強力なリファレンス/インデックス機能
• ドキュメント自動化に必須となる各種インクルード機能
ドキュメントを作りたくなってしまう魔法のツール
ドキュメンテーションツールの一例

26. Operation Lab
運用設計ラボ
Sphinxのインストール
awscli同様、PIPでインストール
> sudo pip install sphinx
ドキュメンテーションツールの一例
> sudo pip install awscli

27. Operation Lab
運用設計ラボ
Sphinxのデモ
ドキュメンテーションツールの一例

28. Operation Lab
運用設計ラボ
宣伝

29. Operation Lab
運用設計ラボ
JAWS-UG CLIを設立しました
• JAWS-UG 初のプロダクト専門支部 (自称)
• 興味対象は、Unified AWS CLI
• (AWS APIやCloudFormationを含む)
• 設立 2014-7-17
• AWS Summit Day1

30. Operation Lab
運用設計ラボ
JAWS-UG CLI勉強会 #0 (7/28 茅場町)
• ハンズオン中心の相互勉強会
• コワーキングスペースを利用 (若干の参加費用)
• 「こんなことするには、どうCLI使う?」を重視
• 後半は、雑談タイム。
• AWS CLIは膨大なので、定期(月1-2回程度)開催予定。