タイトルにもあるが、運用手順書をテーマにしたLTがあった為、
"Outputする人だけが参加出来る#ssmjp"に参加してみた。
その時の感想なり、考えをまとめてみた。
場所はキラキラな虎ノ門ヒルズ。だが天気は雨、そして風邪気味。

初めてのOutputになります。大目に見てやってください(笑)
↑ここ重要↑

勉強会のラインナップ

・CloudGarage様 (10分)
・“JAWS-UGコミュニティ運用とSSMJPとの比較あれこれ”(20分)
・SphinxCon JP 2018のご紹介(10分)
・ssmjp同人部 (20分)
・“「正しい」運用手順書の書き方”(20分)

いろんなLTがございましたが、一番興味があった ”運用手順書の書き方” をメインにブログを書かさせていただきます。
(他LT登壇者の方には申し訳ないです。。すみません。。)

▶ 登壇者

登壇者は、運用設計ラボ合同会社 波田野さん。
みんなで手順書を作る会、JAWS-UG 手順書レビュー支部の方。

▶ 資料

LT時の資料は、既に下記ページにて公開済み。
「正しい」運用手順書を作る

▶ 所感 (思った所、感じた所、学んだ所)

今回のLTで、以下の大きく2つについての学びがありました。
    ・正しい手順書作成が運用自動化への一歩
    ・正しい手順書を作る為の条件

- 学び 1. 正しい手順書作成が運用自動化への一歩

今までは、自分は運用手順書作成に対し、オペレータが作業時にミスさせないよう、わかりやすくをモットーに作成してきた(つもりだ)。

事前に私が、本LTを聞く前に期待した事は
「他のエンジニアたちが”ミスなく作業をする為”の手順書作成はどのように書いてて、どんな工夫をしているのか」
の話が聞けると勝手に想像していた。

”手順の標準化をしよう、そしたら自動化もできるよね”という考えは、恥ずかしながら、最初から自分の頭の中にまったくなかった。

手順書とは別の頭で、”運用自動化やりたい”という気持ちは持っていた。
気持ちばかり先走り、自動化させるための手段・ツール(PythonやAnsible等)に目を向けがちで、まずは自動化の対象を決めてあげる必要があった事に気づく。(ツールがどんなものかを勉強することはよいとは思うが。)
何を、どうやって標準化させるかを考える事が大事そうだ。＜一つ目の学び。＞

上記は波田野さんのLTの中で使用された資料の一部。
手順書を定型化させる所まで作りこんで、初めて運用自動化のステップに行ける。目先のやりたい気持ちに踊らされて、運用自動化に進むと失敗してしまうとの事。

では、どうやって手順書を定型化させるのかが、次の学び。

- 学び 2.正しい手順書を作る為の条件

手順書を作るのに何個かステップがある。
まずは論理的に正しい手順書である事。
それができたら、合目的的な手順書である事をめざす。
努力しだいでステップ２までは習得可能。＜二つ目の学び。＞

機械に手順をやらせ、正しく、目的通りに達成できる手順書をめざす。
本来手順書は、 事前確認>システムを変更>事後確認 を繰り返す。
事前も事後も変更に対して意味あるものでないとだめ。

オペレータが手順書通りに作業を実施しても想定した結果が得られない。目的が反れしまった手順書は、手順書として破たんしている。
当たり前のことがここでは書かれているが、なかなか意識して書かないと難しい。

普段から手順書を作成する時に、ここまで意識して作成はできていなかったなと感じた。
新しい職場に行けば、その職場独自の手順書フォーマットがあり、目の前の作業に対し、フォーマットに沿った形で手順書を大量生産してきた。

その中でも意識してきたと所といえば、冒頭でも書いたが、オペレータがミスしないように、手順が迷わないように(自分視点で)わかりやすく書くという点。
諸先輩方の教えでもある ”誰でもわかるように書きなさい”  ”手順書を使うオペレータの低いレベルの方に合わせなさい” を意識し、オペレータに優しい手順書を目指した結果、あれもこれも書きすぎてしまう。
目的を達成させるための手順として、しっかりと作りこもうとというのはわかるが、”書きすぎてもダメ、書かなさ過ぎてもダメ”は本当に難しい。

それぞれの項目でやらないといけない所をまとめると、

- 論理的：
・手順として一貫性があるか。
・分岐条件や、同一手順の中での繰り返す共通手順は、作成時に極力使わないようにする。(シンプル化)

- 合目的的：
・手順書通り実施したら、その目的が達成できる手順書。
・オペレータが何を目的に作業をするのかを明確にさせる為、手順書の目的(ゴール)を明記する。

- 自分たちが作ってきた手順書を振り返る

職場でよくみる、個人的にダメだなと思う手順書達を一歩引いた眼で見てみる。
・その時の作成者/オペレータしかわからない手順書
ささみのほん2に記載されていた内容だが、”手順1.SV-Aへのログイン”と記載されている手順書。
SV-Aへのログインする為の手順が記載されていなかったり、ID/PASSが記載がない、もしくは在処が記載されておらず、第三者が見ても全く分からない手順書になってしまっている物。
→目的を達成させたいが、そもそもどうやって作業を進むかを記載がされておらず、基本的な情報が少ない。伝承性がない手順書。

・いつになっても改善されない手順書：
手順の不足箇所や誤りを、オペレータが作業時に気づけたが、作業に没頭するあまりに、指摘せずに放置してしまっている手順書。
何度その手順をやっても、毎回同じ所でつまずく手順書。
誤った結果が書いてあることに対し ”あーこれ誤りだから” とわかってて飛ばしてしまう人もいれば、初めて対応した人は、なんでこういう結果になるんだっけと変につまずいてしまう人もいる。
→目的達成(作業完遂)ばかりに目が行きがちで、その場しのぎの手順書になりつつある手順書。伝承性がない。目的を見失ってしまう手順書。

・内容を書きすぎな手順書：
シンプルにオペレータに優しい手順書を目指した結果、あれもこれも書きすぎてしまう。
→読み手にとってわかりづらい手順書。目的を見失ってしまう手順書。

良い部分もあった。
・作業項目を大項目、中項目、小項目の構成で分けて記載できている。
・作業手順書の初めに作業目的と条件を明記できている。
    →登山と同じイメージではないが、道順(ざっくりとした作業項目)が明記されていることで頂上(目的)を見失う事を防げる手順書は作成できていると感じた。作業前に斜め読みしやすく、作業目的が追いやすい手順書は良。

自分がやりたいこと

まずは運用自動化をさせるための手順書を決める。
なるべく影響度の少ない、いつもやる手順書を見つけてきて、その手順書のシンプル化を目指す。
それと並行して、大好きな運用自動化のツールを組み合わせていこうと思った。

以下はLT中に記載したメモで、資料にない事、重要な事を記載してみた。

- みんな大好き運用自動化、でも、みんな大苦手な運用手順書
- なぜ、運用手順書ができないのに、運用自動化ができると思うのだろうか
- 基本的にはコードレベルまで手順書に実装して起こすべき
- ただし、定型化と運用自動化の間に深い深い谷間があり、そもそも実装できないのが現実- 渡された手順書。上から下まで正しければ、間違えない
- 手順書は論理的に書けることが全て
- 日本は論理的な物がなかなか通じない
- 手順書通りに作業をすれば、本来の目的を果たせる手順書
- 手順が意味的に正しくなければ手順書通りに実施しても正しい結果にはならない
- 書かれたことをやっても成長できない
- 読み手が手順書を正確に理解し、記述の真意を容易に把握することができる手順書- 書きすぎてもだめ。書かなすぎてもだめ
- 作業ができるけど、意味を理解できていない手順書はよくない。(ほとんどこれ)
- 良い手順書がオペレータを育てる
- 論理的に正しい事を重視できる人は、運用手順書が得意
- コーディング能力を身につけるとさらに運用自動化もできる
- 運用手順書が苦手な人は、そのまま実装しようとするので運用自動化も破たん
- 運用自動化には、不要なノイズの除去できる大きな役割がある
- 不要な分岐や曖昧な条件、無駄な確認がなくなり、バグがなくなるような効果- ストーリーの保持が大事
- 宣言型の記述をするツールで失われがち- 情報処理学会 ドキュメントコミュニケーション研究会
- 運用自動化の法則にも資料があるのでみてみて
- 運用自動化でsphinxがないと困るので使ってください

他の講義は以下で簡単にメモ程度記載させて頂きます。
説明頂いた皆様、ほんとに申し訳ないです。**
1.Cloud storageってなにとの紹介。**
 - テックサポートブログを書いてみた。
 - 無料クーポン配布(6core/12G/400G)

2.“JAWS-UGコミュニティ運用とSSMJPとの比較あれこれ”
- JAWS-UG(AWS)のコミュニティ。日本以外にも支店がある。
- JAWS-days
- Security-JAWSの話。
- AWSとセキュリティが絡んでたらOK,
- xTech(何かとITを組み合わせたもの) X-Techは違う。
- コミュニティのドタキャン率を減らすのはどうしたらいいのか？
- 運営していく上で結構悩みのタネ。
- コミュニティでのマニフェストがある。
- Github上でJAWS-UGのマニフェストが載っている。
- コミュニティに参加する時は情報クレクレ状態だった。
- コミュニティを関わってくると先の情勢を知ろうとする頭になった。
- グループマネージメント力の向上。
- コミュニティ運営同士の会話から始まる知識向上とGive and Takeの連鎖。
- 世のためにもなる。
- KDDI DevRelやっていきたい。資料がいい感じなので。みてみて。

3.SphinxCon JP 2018のご紹介
- Sphinxのカンファレンスが今月やるのでその宣伝。
- プレーンテキストをインプットして、様々なフォーマットをアウトプットするドキュメントコンバータ。
- phythonのリファレンスを書くツールだったが、できがよかったので、世界的に広まっている。
- Sphinxは日本人が結構メンテナーのかたが多いので質問しやすい環境。