2015-10-31 クラウドネイティヴ時代の運用を考える〜...

Operation Lab運用設計ラボ

クラウドネイティヴ時代の運用を考える

運用設計ラボ合同会社シニアアーキテクト波田野裕一

2015-10-31第5回 Innovation Egg

～ドキュメント駆動運用へ


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


「運用はいつも忙しそうだが何をやっているのかよくわからない」とおっしゃる方がいます、が

本日のお題

「やっている方もよくわかってないんですよ」

と、までは言えませんが、なんだかうまく説明できない。


説明できない、ということは?

赤の他人からは「業務が存在しない」に等しい

赤の他人に理解してもらうには「業務の客観化」が必要

客観化 = 客(ステークホルダ)が観てわかるようにする

人事考課で四苦八苦する


未来の自分は他人

過去を忘れ去った自分からも「業務が存在しない」に等しい

未来の自分に理解してもらうにも「業務の客観化」が必要

客観化 = 客(未来の自分自身)が観てわかるようにする

特に30代後半から顕著

運用「あるある」• 現場の主に聞かないとわからない。

• 現場の主に聞いてもわからない(もう忘れている)

• 現場の主は、もういない… (誰もわからない)


超主観的現場、超属人化

だが、しかし…

運用ドキュメントの悩み


!✓ 作られない/保守されない!‣ 書かない!

!✓ どこにあるかわからない!‣ 読まない!!

✓ 誰が管理しているかわからない!‣ 管理できない!

最近は良い「あるある」がある

• AWSの利用はドキュメント駆動。 • 公式ドキュメントはPDF数千ページ相当ある。 • 有名なブログを見れば、すぐに把握、利用できる。

• (略)

• 個別に書ききれないところは、ベストプラクティスやガイドラインにきっちり準拠させてしまう。



2. そもそもドキュメントとは何か?クラウドネイティヴ時代の運用を考える～ドキュメント駆動運用へ

人はなぜドキュメントを書くのか?


‣ 未来の自分への共有 ‣ 備忘、過去の証跡!‣ 知識、経験の整理、外部化(ノート)!

‣ 行為の定型化 (手順書、チェックリスト)!

‣ 複数人での共有!‣ 備忘、過去の証跡!‣ 認識の共有、確認!‣ 知識の転送!‣ 定型化 (設計、実装、運用)!

‣ 不特定多数との共有!‣ オピニオン/ジャーナリズム!‣ 普遍なるものへ

時を超え

空間を超え

時空の両方を超える

2. そもそもドキュメントとは何か?

人はなぜドキュメントを書くのか?


世界最古のドキュメントは、5300年前のメソポタミアの農作業、牧畜文書

5300年前のメソポタミタの仕事が

21世紀の日本でも再現できる


人は時空を超えて情報共有するためにドキュメントを書く

人はなぜドキュメントを書くのか? (類型)


脱属人化

客観化

整理

記録

客観化

整理

記録

客観化

脱属人化

記録整理

客観化脱属人化

‣ 未来の自分への共有 ‣ 備忘、過去の証跡!‣ 知識、経験の整理、外部化(ノート)!

‣ 行為の定型化 (手順書、チェックリスト)!

‣ 複数人での共有!‣ 備忘、過去の証跡!‣ 認識の共有、確認!‣ 知識の転送!‣ 定型化 (設計、実装、運用)!

‣ 不特定多数との共有!‣ オピニオン/ジャーナリズム!‣ 普遍なるものへ


ドキュメントが実現するもの


脱属人化

客観化

整理

「記録」はドキュメントの本質的な基礎機能記録

「書く」という作業により「整理」されていく

「有形の成果物」となることで「客観化」されていく

時と空間を超えて知験が共有されていく


ドキュメントが実現するもの (レベル分け)


レベル3: 脱属人化

レベル2: 客観化

レベル1: 整理

「記録」はドキュメントの本質的な基礎機能レベル0: 記録

「書く」という作業により整理されていく

「有形の成果物」となることで客観化されていく

時と空間を超えて知識/経験が共有されていく


運用ドキュメントとは


「運用業務に関連して、!自分や他者に共有する目的で、!書かれる文書」のこと


運用ドキュメントはなぜ必要か


脱属人化のために必要

客観化のために必要

整理のために必要「自分達のやっていることを知る&改善するために」

「自分達のやっていることの説明&(自己・他者)評価のために」

「自分達のやっていることの安定化&永続化のために」



3. ドキュメントを作るなら価値を考えようクラウドネイティヴ時代の運用を考える～ドキュメント駆動運用へ

1. 利用者から見た利用価値 (使ってナンボ)!

2. 提供者から見た提供価値 (費用対効果)


運用ドキュメント 2つの価値3. ドキュメントを作るなら価値を考えよう


一般的に「ドキュメント」と言われるものは非常に多種に渡り、その価値は多様

運用ドキュメントは「共有する目的」で書かれる文書

その価値は第一義的には「いかに使われたか」(利用価値)で評価できる

1. 利用価値3. ドキュメントを作るなら価値を考えよう

1. 利用価値 (その誕生から増幅へ)

‣ 反復利用されてはじめて価値が生まれる ‣ 使いたいときに使える。反復利用が可能である。!‣ 可用性 (Available)!

‣ 更新を継続することで価値(信頼)が高まる。 !‣ 間違いが最小限(かつ最新)である。!‣ 信頼性 (Reliability)!

‣ (部品)再利用により、ドキュメント数が増幅する!‣ 利用機会の増大!‣ 保守性 (Serviceability)


3. ドキュメントを作るなら価値を考えよう

1. 利用価値 (価値の計測)


‣ 一般的に「ドキュメント」と言われるものは非常に多種に渡り、その価値も多様である。

‣ 運用ドキュメントのように「使われてナンボ」と考えた場合、以下のようなベンチマークでその価値を評価できる。

読者の範囲を固定した場合、参照回数、利用期間の2つがドキュメント価値の重要な要素となる。

•読者の範囲 ◦水平方向: 社会的範囲 (特定現場～不特定多数) ◦垂直方向: 社会的地位 (専門層/経営層～一般層)

•参照回数 •利用期間(寿命)


1. 利用価値 (価値を低減させるもの)


• 時間の経過とともにドキュメントは経年劣化(陳腐化)していく。

• 信頼低下や陳腐化したドキュメントは利用されなくなり、利用価値を失っていく。

•可用性低下による利用価値低減 • 使いたいときにドキュメントを利用できない。

•信頼性低下による利用価値低減 • ドキュメントが信頼できない。

•再利用性(保守性)低下による利用価値低減 • ドキュメントの維持保守ができない。(提供機会の増大どころではない。)


ドキュメント!書く意味ないよね

運用現場のとある声


利用価値をどう維持するかがキモ



ドキュメントを提供する側では、そのドキュメントの作成維持に無限のリソースを使用することはできない

ドキュメントの提供に関わる費用対効果が問われる

定性的/定量的な費用対効果で評価し、注力すべきドキュメントにリソース集中

2. 提供価値3. ドキュメントを作るなら価値を考えよう

2. 提供価値 (ドキュメントの費用対効果)

‣ 反復利用の多さで工数説明のしやすさが変わる • 反復利用の多いドキュメントは工数説明がしやすい!• 反復利用の少ないドキュメントは工数説明がしにくい!

‣ 陳腐化の早さで掛けるべき工数が変わる!• 陳腐化の早いドキュメントに工数を掛けるのは費用対効果が見あわない!• 陳腐化の遅いドキュメントでも保守しなければ陳腐化(経年劣化)が進む!

‣ 再利用性の高さで陳腐化の早さが変わる!• 再利用性の高いドキュメントは陳腐化を回避しやすい!• 再利用性の低いドキュメントは陳腐化を回避しにくい (手間がかかる)



2. 提供価値 (運用ドキュメントの資産性・費用性)


反復利用、再利用性の高さと、陳腐化の早さに着目して、その運用ドキュメントの価値属性(資産性、費用性)を評価することができると考えられる。

資産性ドキュメント

費用性ドキュメント

• 反復利用・部品再利用性の高いドキュメント!• 変更差分の継続更新により陳腐化回避を実現しているドキュメント

• 反復利用、部品再利用性の低いドキュメント!• 差分更新の効果が低く、作成直後をピークに以後陳腐化していくドキュメント


ドキュメントテーマの3類型


時間軸 activity活動

状態

変化前変化後

変化SCA分析 (仮称)

‣Status(状態)

‣Change(変化)

‣Activity (活動)


参考: ドキュメントテーマによる価値 (仮説)


activity活動

変化

状態

• 反復・再利用性の高いドキュメント(資産性ドキュメント)。!• 「変化」「活動」の起点・終点となる最も重要なドキュメント!• 何らかの形で売却できる場合「収益性」があると言える。

• 反復作成されるが再利用はしにくい。(費用性ドキュメント)!

• 「運用の費用対効果」を説明するためのドキュメントとなるため「収益性」があると考えることもできる。!

• 「活動」の蓄積が変化を生む。!• [留意]「変化させない事」が重要とされる業務もある。

• 反復作成されるが再利用はしにくい。(費用性ドキュメント)!

• コストが直接配賦されれば「収益性」があるが、共通配賦される場合は、作成自体が「運用コスト」と評価される。

ドキュメントテーマ





状態

変化前変化後

変化資産性ドキュメント


収益性ドキュメント

主観: ヒト客観: システム

工数をかけるべき

工数をかけても!無駄



資産性・費用性 (一般的な例)


資産性ドキュメント費用性ドキュメント

‣要求仕様書

‣システム/企画提案書

‣説明書/マニュアル

‣設計仕様書 ‣技術論文

‣状態分析レポート (定期)

‣調査レポート (定期)

‣手順書 (マスター/テンプレート)

‣構成図 ‣運用設計書 ‣作業カタログ ‣リポジトリ

‣作業報告書 (都度)

‣日報/週報/月報 (都度)

‣電子メール/FAX (都度)

‣注文書 (都度)

‣依頼状 (都度)

‣案内状 (都度)

‣質問書 (都度)

‣回答書 (都度)

‣状態分析レポート (スポット)

‣調査レポート (スポット)

費用性ドキュメントのマスターテンプレートや、検索可能な状態での共有データなどは資産性を持つ。コストセンターと言われがちな運用現場の!

産み出す唯一の有形資産、とも言える。

工数をかけるべき工数をかけても!無駄かも


ドキュメント!書くの大変

運用現場のとある声


提供価値と工数のバランスがキモ


1. 利用者から見た利用価値 (使ってナンボ)!

2. 提供者から見た提供価値 (費用対効果)


運用ドキュメントは価値ドリブンで作成

ドキュメントの作成は!計画的に



4. ドキュメンテーション技術の進展クラウドネイティヴ時代の運用を考える～ドキュメント駆動運用へ

人はなぜドキュメントを書くのか? (再)


人は時空を超えて情報共有するためにドキュメントを書く

世界最古のドキュメントは、

5300年前のメソポタミアの農作業、牧畜文書5300年前の仕事が再現できる

4. ドキュメンテーション技術の進展

ドキュメントの歴史 (紀元前～19世紀)


手書きドキュメントの誕生 (粘土板)5300年前 (紀元前3300年)

1800年前 (2世紀) 手書きドキュメントの量産化 (紙)

1300年前 (7世紀) 定型ドキュメントの出力自動化 (木版印刷)

500年前 (15世紀) 定型ドキュメントの量産化 (活版印刷)

200年前 (18世紀末) 定型ドキュメントの大量生産化 (平版印刷)

150年前 (19世紀後半) 非定型ドキュメントの出力自動化 (タイプライタ)

約5300年にわたる「ドキュメント出力」の歴史


ドキュメントの歴史 (20世紀末～21世紀初頭)


30年前 (1980年代後半) オンデマンドな「編集」技術の登場 (ワープロの普及)

20年前 (1990年代後半) デジタル手書きドキュメントの量産化 (Excel)

15年前 (2000年代前半) ドキュメント自動変換技術の登場 (Webセマンティック)

約20年にわたる「ドキュメント編集」の歴史


ドキュメントの歴史 (21世紀)


10年前 (2000年代後半) セマンティック技術の普及

今後

これからは「ドキュメント生成」の分担がテーマ

5年前 (2010年代前半) 構造化記法の普及 (自動生成の容易化)

ドキュメント設計の時代へ1. セマンティック技術と構造化記法の自然な融合!2. 何を人が書き、何をシステムが書くか!3. 「全てデジタル手書き」という時代からの脱却



ドキュメント技術は激変する4. ドキュメンテーション技術の進展

ドキュメントの生成

ドキュメントのオンデマンド編集

ドキュメントの出力

開始

完了

紀元前～19世紀20世紀末～21世紀初頭21世紀(これから)

約5300年にわたる

「ドキュメント出力」の歴史

約20年にわたる

「ドキュメント編集」の歴史

約数年にわたる「ドキュメント自動生成」

の未来

何を人が書き!何をシステムが書くか

ドキュメントの技術は出口側から発達してきた。

5～10年以内に +機械学習?




状態

変化前の状態変化後の状態

変化資産性ドキュメント


収益性ドキュメント

主観: ヒト客観: システム


機械に!書かせるべき

人が書くべき!機械にも書かせるべき



5. クラウド時代の運用ドキュメントクラウドネイティヴ時代の運用を考える～ドキュメント駆動運用へ

「運用自動化」の前に

ドキュメントは!ソースコードでいいよね

自動化クラスタのとある声


ダメゼッタイ

ダメ

5. クラウド時代の運用ドキュメント

運用には5W1Hが必要


when

where

who

what

how

いつ (時間)

どこで (空間)

誰が (主語・主体)

何を (目的語・客体)

どうする (動作)

運用自動化

ソースコード

why なぜ (根本的な意図)

テストコード

抜け落ちる


運用には5W1Hが必要


why

運用はWhy(なぜ)が命Whyの無い運用ドキュメントは

引き継ぎ不可能(に近い)



参考: 自動化は「目的」ではない自動化は、「ドキュメント化の結果」であって「目的」ではない。

「自分達のやっていることの安定化&永続化のために」目的:

手段: 自動「ドキュメント化された業務の一部」を自動化する。

目的と手段がひっくりかえることは、よくあること

• 「自動化された業務」の保守が属人化する。 • 「自動化された業務」の仕様が不明なため、変更ができない。(地雷状態) • 「自動化された業務」でトラブルが発生すると、自動化ツールの修正が完了するまでリカバリができない。(手順がわからない)

「自動化が目的」による「あるある」

2014年の発表資料より5. クラウド時代の運用ドキュメント


6. クラウド時代のドキュメンテーション手法クラウドネイティヴ時代の運用を考える～ドキュメント駆動運用へ

クラウドネイティブ時代のドキュメンテーション技術

1. 分散バージョン管理システムを使う。

2. 構造化記法を使う。

3. 分散化と構造化と非同期更新を意識する。


6. クラウド時代のドキュメンテーション手法

1. 分散バージョン管理システムを使う

• Git: プログラムの仕様ドキュメント向き • Mercurial: 一般的なドキュメント向け


(主観です)

• コミットログをきっちり運用できるならば(世間的には)Git。 • 版数管理とドキュメント保全が主眼ならMercurialがオススメ。


2. 構造化記法を使う (今後の要件)


• バージョン管理と相性が良いテキストドキュメント

• 記法が日常のメモと違和感がない

• 1つのソースコードで複数形式で出力 (PDF/HTML)

• 外部ドキュメントをインクルードできる (非同期更新)


3. 分散化と構造化と非同期更新を意識する

• 分散化: サブリポジトリの活用 • ソースリポジトリ全体はツリー構造 • メインタイプのドキュメントリポジトリ (ツリートップ) • サブタイプのドキュメントリポジトリ (サブツリー)

• 非同期更新: 外部ドキュメントのinclude多用 • 構造化: ここがドキュメント作成のキモ



Operation Lab��

主張: クラウド時代の運用設計/ドキュメント

「問題を根性で解決するのは馬鹿です。問題をエンジニアリングで解決するのが

エンジニアの仕事です」 @yoshiori

構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。工学では何らかの構造物・構造体を作ることが不可避なためです。

http://d.hatena.ne.jp/Yoshiori/20120217/1329491437


ドキュメント構造化


• 文章ブロック単位での意味付け (見出し) • 単位情報の責務の明確化 (オブジェクト化)

• 読み手が認識しやすい位置への文章ブロックの格納 (目次) • 情報をツリー構造で表現 (構造化)

• 文章ブロック間の関係付け (クロスリファレンス) • 情報内ネットワーク構造の構築 (ネットワーク化)


ドキュメント構造化の効果


• 書き手が書きやすい • 逆説的だが、対象を構造化しなければ書けないため、構造化して

捉えなおしたものは書きやすい

• 読み手が読みやすい • 構造化されたドキュメントは全体を把握しやすく、拾い読みもで

きる

• 半自動化が可能になる • 人とシステムでドキュメントツリーの各部分の作成を分担できる



7. クラウド時代のドキュメンテーションデモクラウドネイティヴ時代の運用を考える～ドキュメント駆動運用へ

構造化記法を使う例


• オープンソースのドキュメンテーションビルダ • 元々はPythonによるPythonドキュメントのための実装 • Sphinx1.0以降は、Pythonに特化した機能が分離されて汎用化 • BSDライセンス

• マークアップ言語としてreSTructured Textを利用 • 基本書式は普通のテキストメモに見える。 • テキストファイルなのでバージョン管理が簡単。

• ドキュメント作成に嬉しい多様な機能 • ワンソースマルチアウトプット (html / PDF / text / manなど) • 独自拡張可能なディレクティブ、ロール、テーマ

7. クラウド時代のドキュメンテーションデモ


Sphinxに興味を持ったら

http://qiita.com/tcsh/items/ce758fd45f748463c4b9「コピペで体験してみるSphinx」ハンズオン

• まずさわってみよう • #1 Sphinx Quick Start • #2 入門編 (メモ書きからはじめる)

• Webコンテンツを作成してみよう • #3 基礎編 (ディレクティブとロール for Web)

• ドキュメントを構造化してみよう • #4 ドキュメント構造化 (初級: 複数ファイルを扱う) • #5 ドキュメント構造化 (中級: 外部ドキュメント連携)


8. まとめクラウドネイティヴ時代の運用を考える～ドキュメント駆動運用へ

運用ドキュメントに何を書くのか?


1. 使う人の範囲!‣ 自分、特定の現場、不特定多数!

2. 対象時間の範囲!‣ 過去、現在、未来、普遍!

3. ドキュメントテーマ!‣ 3類型 (状態 / 変化 / 活動)

ドキュメントのスコープと目的を決めることでぼんやりとではあるが見えてくる。あとは経験。

脱属人化

客観化

整理

記録

スコープ目的

8. まとめ

ドキュメントありきの運用へ

‣ アンドキュメンテッド運用からの脱却!‣ 属人的(ブラックボックス/高負荷)運用からの脱却!‣ 工学的視点に立つ高度で合理的(説明可能)な運用へ!‣ クラウドに喰われない(共存する)、運用の生き残り!

‣ 100%手書き/属人的なドキュメント作成からの脱却!‣ ITサービスの提供者がちゃんとITする(自動化)時代へ!‣ 適切な自動化には構造化が、適切な構造化には抽象化が必要!‣ 工学的視点に立つ高度なドキュメントロジックへ


ドキュメント駆動運用へ

8. まとめ


http://www.operation-lab.co.jp/

OperationLab運用設計

2015-10-31 クラウドネイティヴ時代の運用を考える 〜...

Engineering

2015-10-31 クラウドネイティヴ時代の運用を考える〜...