2015-10-31 クラウドネイティヴ時代の運用を考える〜ドキュメント駆動運用へ

Operation Lab
運用設計ラボ
クラウドネイティヴ時代の運用を考える
運用設計ラボ合同会社
シニアアーキテクト波田野裕一
2015-10-31
第5回 Innovation Egg
∼ ドキュメント駆動運用へ

Operation Lab
運用設計ラボ
1. ドキュメント書いてますか?
クラウドネイティヴ時代の運用を考える ∼ ドキュメント駆動運用へ

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

Operation Lab
運用設計ラボ
説明できない、ということは?
赤の他人からは
「業務が存在しない」に等しい
赤の他人に理解してもらうには
「業務の客観化」が必要
客観化 = 客(ステークホルダ)が観てわかるようにする
人事考課で四苦八苦する

Operation Lab
運用設計ラボ
未来の自分は他人
過去を忘れ去った自分からも
「業務が存在しない」に等しい
未来の自分に理解してもらうにも
「業務の客観化」が必要
客観化 = 客(未来の自分自身)が観てわかるようにする
特に30代後半から顕著

運用「あるある」
• 現場の主に聞かないとわからない。
• 現場の主に聞いてもわからない(もう忘れている)
• 現場の主は、もういない… (誰もわからない)
Operation Lab
運用設計ラボ
超主観的現場、超属人化
だが、しかし…

運用ドキュメントの悩み
Operation Lab
運用設計ラボ
!
✓ 作られない/保守されない!
‣ 書かない!
!
✓ どこにあるかわからない!
‣ 読まない!
!
✓ 誰が管理しているかわからない!
‣ 管理できない!

最近は良い「あるある」がある
• AWSの利用はドキュメント駆動。
• 公式ドキュメントはPDF数千ページ相当ある。
• 有名なブログを見れば、すぐに把握、利用できる。
• (略)
• 個別に書ききれないところは、ベストプラクティス
やガイドラインにきっちり準拠させてしまう。
Operation Lab
運用設計ラボ

Operation Lab
運用設計ラボ
2. そもそもドキュメントとは何か?

人はなぜドキュメントを書くのか?
Operation Lab
運用設計ラボ
‣ 未来の自分への共有
‣ 備忘、過去の証跡!
‣ 知識、経験の整理、外部化(ノート)!
‣ 行為の定型化 (手順書、チェックリスト)!
‣ 複数人での共有!
‣ 認識の共有、確認!
‣ 知識の転送!
‣ 定型化 (設計、実装、運用)!
‣ 不特定多数との共有!
‣ オピニオン/ジャーナリズム!
‣ 普遍なるものへ
時を超え
空間を超え
時空の両方
を超える

人はなぜドキュメントを書くのか?
Operation Lab
運用設計ラボ
世界最古のドキュメントは、5300年前のメソポタミアの農作業、牧畜文書
5300年前のメソポタミタの仕事が
21世紀の日本でも再現できる
人は時空を超えて情報共有するために
ドキュメントを書く

人はなぜドキュメントを書くのか? (類型)
Operation Lab
運用設計ラボ
脱属人化
客観化
整理
記録
客観化
整理
記録
客観化
脱属人化
記録整理
客観化脱属人化
‣ 未来の自分への共有
‣ 知識、経験の整理、外部化(ノート)!
‣ 行為の定型化 (手順書、チェックリスト)!
‣ 複数人での共有!
‣ 認識の共有、確認!
‣ 知識の転送!
‣ 定型化 (設計、実装、運用)!
‣ 不特定多数との共有!
‣ オピニオン/ジャーナリズム!
‣ 普遍なるものへ

ドキュメントが実現するもの
Operation Lab
運用設計ラボ
脱属人化
客観化
整理
「記録」はドキュメントの本質的な基礎機能記録
「書く」という作業により「整理」されていく
「有形の成果物」となることで「客観化」されていく
時と空間を超えて知験が共有されていく

ドキュメントが実現するもの (レベル分け)
Operation Lab
運用設計ラボ
レベル3: 脱属人化
レベル2: 客観化
レベル1: 整理
「記録」はドキュメントの本質的な基礎機能
レベル0: 記録
「書く」という作業により整理されていく
「有形の成果物」となることで客観化されていく
時と空間を超えて知識/経験が共有されていく

運用ドキュメントとは
Operation Lab
運用設計ラボ
「運用業務に関連して、!
自分や他者に共有する目的で、!
書かれる文書」のこと

運用ドキュメントはなぜ必要か
Operation Lab
運用設計ラボ
脱属人化のために必要
客観化のために必要
整理のために必要
「自分達のやっていることを知る&改善するために」
「自分達のやっていることの説明&(自己・他者)評価のために」
「自分達のやっていることの安定化&永続化のために」

Operation Lab
運用設計ラボ
3. ドキュメントを作るなら価値を考えよう

1. 利用者から見た利用価値 (使ってナンボ)!
2. 提供者から見た提供価値 (費用対効果)
Operation Lab
運用設計ラボ
運用ドキュメント 2つの価値

Operation Lab
運用設計ラボ
一般的に「ドキュメント」と言われるものは非常に多種に渡り、その価値は多様
運用ドキュメントは「共有する目的」で書かれる文書
その価値は第一義的には「いかに使われたか」
(利用価値)で評価できる
1. 利用価値

1. 利用価値 (その誕生から増幅へ)
‣ 反復利用されてはじめて価値が生まれる
‣ 使いたいときに使える。反復利用が可能である。!
‣ 可用性 (Available)!
‣ 更新を継続することで価値(信頼)が高まる。 !
‣ 間違いが最小限(かつ最新)である。!
‣ 信頼性 (Reliability)!
‣ (部品)再利用により、ドキュメント数が増幅する!
‣ 利用機会の増大!
‣ 保守性 (Serviceability)
Operation Lab
運用設計ラボ

1. 利用価値 (価値の計測)
Operation Lab
運用設計ラボ
‣ 一般的に「ドキュメント」と言われるものは非常に多種に渡り、その
価値も多様である。
‣ 運用ドキュメントのように「使われてナンボ」と考えた場合、以下の
ようなベンチマークでその価値を評価できる。
読者の範囲を固定した場合、参照回数、利用期間の2つが
ドキュメント価値の重要な要素となる。
• 読者の範囲
◦水平方向: 社会的範囲 (特定現場 ∼ 不特定多数)
◦垂直方向: 社会的地位 (専門層/経営層 ∼ 一般層)
• 参照回数
• 利用期間(寿命)

1. 利用価値 (価値を低減させるもの)
Operation Lab
運用設計ラボ
• 時間の経過とともにドキュメントは経年劣化(陳腐化)していく。
• 信頼低下や陳腐化したドキュメントは利用されなくなり、利用価値を失っていく。
• 可用性低下による利用価値低減
• 使いたいときにドキュメントを利用できない。
• 信頼性低下による利用価値低減
• ドキュメントが信頼できない。
• 再利用性(保守性)低下による利用価値低減
• ドキュメントの維持保守ができない。(提供機会の増大どころではない。)

ドキュメント!
書く意味ないよね
運用現場のとある声
Operation Lab
運用設計ラボ
利用価値をどう
維持するかがキモ

Operation Lab
運用設計ラボ
ドキュメントを提供する側では、そのドキュメントの作成維持に無限のリソース
を使用することはできない
ドキュメントの提供に関わる費用対効果が問われる
定性的/定量的な費用対効果で評価し、注力すべき
ドキュメントにリソース集中
2. 提供価値

2. 提供価値 (ドキュメントの費用対効果)
‣ 反復利用の多さで工数説明のしやすさが変わる
• 反復利用の多いドキュメントは工数説明がしやすい!
• 反復利用の少ないドキュメントは工数説明がしにくい!
‣ 陳腐化の早さで掛けるべき工数が変わる!
• 陳腐化の早いドキュメントに工数を掛けるのは費用対効果が見あわない!
• 陳腐化の遅いドキュメントでも保守しなければ陳腐化(経年劣化)が進む!
‣ 再利用性の高さで陳腐化の早さが変わる!
• 再利用性の高いドキュメントは陳腐化を回避しやすい!
• 再利用性の低いドキュメントは陳腐化を回避しにくい (手間がかかる)
Operation Lab
運用設計ラボ

2. 提供価値 (運用ドキュメントの資産性・費用性)
Operation Lab
運用設計ラボ
反復利用、再利用性の高さと、陳腐化の早さに着目して、その運用
ドキュメントの価値属性(資産性、費用性)を評価することができる
と考えられる。
資産性ドキュメント
費用性ドキュメント
• 反復利用・部品再利用性の高いドキュメント!
• 変更差分の継続更新により陳腐化回避を実現しているドキュメント
• 反復利用、部品再利用性の低いドキュメント!
• 差分更新の効果が低く、作成直後をピークに以後陳腐化していく
ドキュメント

ドキュメントテーマの3類型
Operation Lab
運用設計ラボ
時間軸 activity活動
状
態
変化前変化後
変化
SCA分析 (仮称)
‣Status(状態)
‣Change(変化)
‣Activity (活動)

参考: ドキュメントテーマによる価値 (仮説)
Operation Lab
運用設計ラボ
activity活動
変化
状
態
• 反復・再利用性の高いドキュメント(資産性ドキュメント)。!
• 「変化」「活動」の起点・終点となる最も重要なドキュメント!
• 何らかの形で売却できる場合「収益性」があると言える。
• 反復作成されるが再利用はしにくい。(費用性ドキュメント)!
• 「運用の費用対効果」を説明するためのドキュメントとなるた
め「収益性」があると考えることもできる。!
• 「活動」の蓄積が変化を生む。!
• [留意]「変化させない事」が重要とされる業務もある。
• 反復作成されるが再利用はしにくい。(費用性ドキュメント)!
• コストが直接配賦されれば「収益性」があるが、共通配賦され
る場合は、作成自体が「運用コスト」と評価される。
ドキュメントテーマ

Operation Lab
運用設計ラボ
状
態
変化前変化後
変化
収益性ドキュメント
主観: ヒト
客観: システム
工数をかけるべき
工数をかけても!
無駄

資産性・費用性 (一般的な例)
Operation Lab
運用設計ラボ
資産性ドキュメント費用性ドキュメント
‣要求仕様書
‣システム/企画提案書
‣説明書/マニュアル
‣設計仕様書
‣技術論文
‣状態分析レポート (定期)
‣調査レポート (定期)
‣手順書 (マスター/テンプレート)
‣構成図
‣運用設計書
‣作業カタログ
‣リポジトリ
‣作業報告書 (都度)
‣日報/週報/月報 (都度)
‣電子メール/FAX (都度)
‣注文書 (都度)
‣依頼状 (都度)
‣案内状 (都度)
‣質問書 (都度)
‣回答書 (都度)
‣状態分析レポート (スポット)
‣調査レポート (スポット)
費用性ドキュメントのマスターテンプレートや、
検索可能な状態での共有データなどは資産性を持つ。
コストセンターと言われがちな運用現場の!
産み出す唯一の有形資産、とも言える。
工数をかけても!
無駄かも

ドキュメント!
書くの大変
運用現場のとある声
Operation Lab
運用設計ラボ
提供価値と工数の
バランスがキモ

1. 利用者から見た利用価値 (使ってナンボ)!
2. 提供者から見た提供価値 (費用対効果)
Operation Lab
運用設計ラボ
運用ドキュメントは価値ドリブンで作成
ドキュメントの作成は!
計画的に

Operation Lab
運用設計ラボ
4. ドキュメンテーション技術の進展

人はなぜドキュメントを書くのか? (再)
Operation Lab
運用設計ラボ
人は時空を超えて情報共有するために
ドキュメントを書く
世界最古のドキュメントは、
5300年前のメソポタミアの農作業、牧畜文書
5300年前の仕事が再現できる

ドキュメントの歴史 (紀元前∼19世紀)
Operation Lab
運用設計ラボ
手書きドキュメントの誕生 (粘土板)5300年前
(紀元前3300年)
1800年前
(2世紀)
手書きドキュメントの量産化 (紙)
1300年前
(7世紀)
定型ドキュメントの出力自動化 (木版印刷)
500年前
(15世紀)
定型ドキュメントの量産化 (活版印刷)
200年前
(18世紀末)
定型ドキュメントの大量生産化 (平版印刷)
150年前
(19世紀後半) 非定型ドキュメントの出力自動化 (タイプライタ)
約5300年にわたる「ドキュメント出力」の歴史

ドキュメントの歴史 (20世紀末∼21世紀初頭)
Operation Lab
運用設計ラボ
30年前
(1980年代後半) オンデマンドな「編集」技術の登場 (ワープロの普及)
20年前
(1990年代後半) デジタル手書きドキュメントの量産化 (Excel)
15年前
(2000年代前半) ドキュメント自動変換技術の登場 (Webセマンティック)
約20年にわたる「ドキュメント編集」の歴史

ドキュメントの歴史 (21世紀)
Operation Lab
運用設計ラボ
10年前
(2000年代後半) セマンティック技術の普及
今後
これからは「ドキュメント生成」の分担がテーマ
5年前
(2010年代前半) 構造化記法の普及 (自動生成の容易化)
ドキュメント設計の時代へ
1. セマンティック技術と構造化記法の自然な融合!
2. 何を人が書き、何をシステムが書くか!
3. 「全てデジタル手書き」という時代からの脱却

Operation Lab
運用設計ラボ
ドキュメント技術は激変する
ドキュメント
の生成
ドキュメント
のオンデマンド編集
ドキュメント
の出力
開
始
完
了
紀元前∼19世紀20世紀末∼21世紀初頭21世紀(これから)
約5300年にわたる
「ドキュメント出力」
の歴史
約20年にわたる
「ドキュメント編集」
の歴史
約数年にわたる
「ドキュメント自動生成」
の未来
何を人が書き!
何をシステムが書くか
ドキュメントの技術は出口側から発達してきた。
5∼10年以内に +機械学習?

Operation Lab
運用設計ラボ
状
態
変化前の状態変化後の状態
変化
収益性ドキュメント
主観: ヒト
客観: システム
機械に!
書かせるべき
人が書くべき!
機械にも書かせるべき

Operation Lab
運用設計ラボ
5. クラウド時代の運用ドキュメント
「運用自動化」の前に

ドキュメントは!
ソースコードでいいよね
自動化クラスタのとある声
Operation Lab
運用設計ラボ
ダメ
ゼッタイ
ダメ

運用には5W1Hが必要
Operation Lab
運用設計ラボ
when
where
who
what
how
いつ (時間)
どこで (空間)
誰が (主語・主体)
何を (目的語・客体)
どうする (動作)
運用自動化
ソースコード
why なぜ (根本的な意図)
テストコード
抜け落ちる

運用には5W1Hが必要
Operation Lab
運用設計ラボ
why
運用はWhy(なぜ)が命
Whyの無い運用ドキュメントは
引き継ぎ不可能(に近い)

Operation Lab
運用設計ラボ
参考: 自動化は「目的」ではない
自動化は、「ドキュメント化の結果」であって「目的」ではない。
「自分達のやっていることの安定化&永続化のために」目的:
手段: 自動「ドキュメント化された業務の一部」を自動化する。
目的と手段がひっくりかえることは、よくあること
• 「自動化された業務」の保守が属人化する。
• 「自動化された業務」の仕様が不明なため、変更ができない。(地雷状態)
• 「自動化された業務」でトラブルが発生すると、自動化ツールの修正が完了する
までリカバリができない。(手順がわからない)
「自動化が目的」による「あるある」
2014年の発表資料より

Operation Lab
運用設計ラボ
6. クラウド時代のドキュメンテーション手法

クラウドネイティブ時代のドキュメンテーション技術
1. 分散バージョン管理システムを使う。
2. 構造化記法を使う。
3. 分散化と構造化と非同期更新を意識する。
Operation Lab
運用設計ラボ

1. 分散バージョン管理システムを使う
• Git: プログラムの仕様ドキュメント向き
• Mercurial: 一般的なドキュメント向け
Operation Lab
運用設計ラボ
(主観です)
• コミットログをきっちり運用できるならば(世間的には)Git。
• 版数管理とドキュメント保全が主眼ならMercurialがオススメ。

2. 構造化記法を使う (今後の要件)
Operation Lab
運用設計ラボ
• バージョン管理と相性が良いテキストドキュメント
• 記法が日常のメモと違和感がない
• 1つのソースコードで複数形式で出力 (PDF/HTML)
• 外部ドキュメントをインクルードできる (非同期更新)

3. 分散化と構造化と非同期更新を意識する
• 分散化: サブリポジトリの活用
• ソースリポジトリ全体はツリー構造
• メインタイプのドキュメントリポジトリ (ツリートップ)
• サブタイプのドキュメントリポジトリ (サブツリー)
• 非同期更新: 外部ドキュメントのinclude多用
• 構造化: ここがドキュメント作成のキモ
Operation Lab
運用設計ラボ

Operation Lab
主張: クラウド時代の運用設計/ドキュメント
「問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのが
エンジニアの仕事です」
@yoshiori
構造化
ここでは「エンジニアリング(工学)の実践」に近い意味で使います。
工学では何らかの構造物・構造体を作ることが不可避なためです。
http://d.hatena.ne.jp/Yoshiori/20120217/1329491437

ドキュメント構造化
Operation Lab
運用設計ラボ
• 文章ブロック単位での意味付け (見出し)
• 単位情報の責務の明確化 (オブジェクト化)
• 読み手が認識しやすい位置への文章ブロックの格納 (目次)
• 情報をツリー構造で表現 (構造化)
• 文章ブロック間の関係付け (クロスリファレンス)
• 情報内ネットワーク構造の構築 (ネットワーク化)

ドキュメント構造化の効果
Operation Lab
運用設計ラボ
• 書き手が書きやすい
• 逆説的だが、対象を構造化しなければ書けないため、構造化して
捉えなおしたものは書きやすい
• 読み手が読みやすい
• 構造化されたドキュメントは全体を把握しやすく、拾い読みもで
きる
• 半自動化が可能になる
• 人とシステムでドキュメントツリーの各部分の作成を分担できる

Operation Lab
運用設計ラボ
7. クラウド時代のドキュメンテーションデモ

構造化記法を使う例
Operation Lab
運用設計ラボ
• オープンソースのドキュメンテーションビルダ
• 元々はPythonによるPythonドキュメントのための実装
• Sphinx1.0以降は、Pythonに特化した機能が分離されて汎用化
• BSDライセンス
• マークアップ言語としてreSTructured Textを利用
• 基本書式は普通のテキストメモに見える。
• テキストファイルなのでバージョン管理が簡単。
• ドキュメント作成に嬉しい多様な機能
• ワンソースマルチアウトプット (html / PDF / text / manなど)
• 独自拡張可能なディレクティブ、ロール、テーマ
7. クラウド時代のドキュメンテーションデモ

Operation Lab
運用設計ラボ
Sphinxに興味を持ったら
http://qiita.com/tcsh/items/ce758fd45f748463c4b9
「コピペで体験してみるSphinx」ハンズオン
• まずさわってみよう
• #1 Sphinx Quick Start
• #2 入門編 (メモ書きからはじめる)
• Webコンテンツを作成してみよう
• #3 基礎編 (ディレクティブとロール for Web)
• ドキュメントを構造化してみよう
• #4 ドキュメント構造化 (初級: 複数ファイルを扱う)
• #5 ドキュメント構造化 (中級: 外部ドキュメント連携)

Operation Lab
運用設計ラボ
8. まとめ

運用ドキュメントに何を書くのか?
Operation Lab
運用設計ラボ
1. 使う人の範囲!
‣ 自分、特定の現場、不特定多数!
2. 対象時間の範囲!
‣ 過去、現在、未来、普遍!
3. ドキュメントテーマ!
‣ 3類型 (状態 / 変化 / 活動)
ドキュメントのスコープと目的を決めることでぼんやりとではあるが
見えてくる。あとは経験。
脱属人化
客観化
整理
記録
スコープ目的
8. まとめ

ドキュメントありきの運用へ
‣ アンドキュメンテッド運用からの脱却!
‣ 属人的(ブラックボックス/高負荷)運用からの脱却!
‣ 工学的視点に立つ高度で合理的(説明可能)な運用へ!
‣ クラウドにわれない(共存する)、運用の生き残り!
‣ 100%手書き/属人的なドキュメント作成からの脱却!
‣ ITサービスの提供者がちゃんとITする(自動化)時代へ!
‣ 適切な自動化には構造化が、適切な構造化には抽象化が必要!
‣ 工学的視点に立つ高度なドキュメントロジックへ
Operation Lab
運用設計ラボ
ドキュメント駆動運用へ
8. まとめ

Operation Lab
運用設計ラボ
http://www.operation-lab.co.jp/
OperationLab運用設計

2015-10-31 クラウドネイティヴ時代の運用を考える〜ドキュメント駆動運用へ

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 2015-10-31 クラウドネイティヴ時代の運用を考える〜ドキュメント駆動運用へ

Similaire à 2015-10-31 クラウドネイティヴ時代の運用を考える〜ドキュメント駆動運用へ (20)