背景
LC4RIの実施における指標・メトリクスを定義することで、「もっと○○したほうがいいよね」とか会話ができるようになるかもしれない。LC4RIをMethodologyの観点で整理したいなあ・・・という欲求に基づいている。
（今は、「とにかくNotebookで書いてみようぜ」(そのあと、思想が伝わることを期待)という布教をしている状態なのを、「この思想ではこういうゴールを規定していて、それを達成するにはこういうサブゴールを達成する必要がある。その1つ目のサブゴールとして、Notebookで書くことをやってみましょう」と布教する形にしたい。教義を単純化・具体化し、わかりやすい効能を定義することで、伝道師が増える効果が期待できると思う, https://qiita.com/yacchin1205/items/8bd1b79942418e0d0888 を一歩整理を進めているという感じかも） LC4RIの目標
LC4RI(Literate Computing for Reproducible Infrastructure)とは、インフラ(運用手順含む)をReproducible Infrastructureとして整備することで、インフラ(運用手順含む)とインフラ運用に関わる人間系(運用者・ベンダー・その他ステークホルダー)の両方に関して、追加コストを抑えながらで高い信頼性を実現するための取り組みである、と定義してみる。
Reproducible InfrastructureをInstanciationしたものの例 ... ABC(Academic Baremetal Cloud) / Elasticsearch on AWS/GCP等
じゃあ、What is Reproducible Infrastructure ? に対する定義が必要
また、LC4RIの実践によりインフラおよびその運用に関する共通言語が定義されることで、異なるインフラ(運用手順含む)間の比較・改善が促進されることを期待している。
LC4RIのアプローチ
どのようにインフラ(運用手順含む)と人間系の両方に関して高い信頼性を実現するかについてであるが、LC4RIでは運用者による実際の運用手順やその証跡を蓄積し、人間系のコミュニケーションを促進することで、インフラ(運用手順含む)の改善を促し、高い信頼性の実現を目指す、と定義してみる。
to describe automated operations as live code
to share predicted and reproducible outcomes among technical and non-technical alike in the form of narrative stories
であると表明している。
まず、describe automated operationsは、コミュニケーションの道具として利用可能な運用手順や実施結果の蓄積を主な目的としていると考えている。従来の運用に比べ経緯の記述、作業をコードとして記述することにより運用者の作業コストが一時的には増大することが予想されるが、人為的な錯誤を避けられる手順・環境の実現や、運用者間で手順の共有がしやすくなることで、従来払っていたコストが削減され追加コストは相殺することができると考えている。
「ドキュメントを開いて運用管理サーバからコマンドを投入、まちがいがないか確認、結果を証跡として wiki にコピペする」なんて所作、機器に隷属させられているような単純作業を軽減する、ドキュメントとコードと証跡を一体として扱える Jupyter Notebookで機械化する辺りから始めませんか？ #機械化_-_自働化じゃなくて share predicted and reproducible outcomes among technical and non-technicalは、インフラ(運用手順含む)を、これに関わる人間が積極的に状況把握・改善活動を進めることを主な目的としていると考えている。従来の手順書はシステム構築ベンダーから運用者への一方通行であり、運用者による運用手順の実施状況や改善提案をベンダーに対してシステマティックにフィードバックできる仕掛けを備えていない。また現状は、発注者などのステークホルダーは、信頼性やコストに関わる実態を直接的に運用現場の情報から把握する方法がない。これらの人間系におけるコミュニケーション不全は、Notebookという共通フォーマットを定義し、インフラの設定・状態を共通言語として明確化していくことで解決できると考えている。
LC4RIのツール
アプローチで挙げた2つの方策それぞれを、具体的にどのような道具で実現するのかは、以下の通り。
describe automated operationsについては、Jupyter NotebookとAnsibleを組み合わせて作業を行うことで(プラクティスを明示する必要あり)達成される。
(これが自動的に達成できるかどうかは、automated operationsの定義に依存する。別項目を立てて詳細に議論した方が良いと思う: 多分みんな色々な解釈を持っている、あと #Human_in_the_Loop も参照) share predicted and reproducible outcomes among technical and non-technicalについては、原則的にはoutcomesが含まれるNotebook群を共有することによって達成されるが、Notebook自体は作成者の作業に対する関心を中心に記述されており、関心を持つにいたる経緯を記述することを推奨しているものの、コンテキストを異にする人同士 or tech / non-tech間で共有可能な経緯の記述を行うことは一般的には難しい。
ここで、tech / non-techの間での共通のinterestとしてのoutcomesは(究極的には)今現在のインフラが果たすことができる機能(=設定と状態)であると考える。(インフラを必要な設定で動かし続けることが、インフラ運用のミッションなので)
したがって、automated operationsの対象となるインフラにおいて、predicted and reproducible outcomesを technical and non-technical 間で共有するためには、以下の2つの条件を満たしている必要があると考えることができる。
Notebookの対象のインフラの設定及び状態が、Notebookによって識別可能な形式で定義されていること
Notebookの操作対象が initialized / healthy あるいは何かサブコンポーネントがavailableであるとNotebookにより判別できる等
Notebookの対象のインフラの設定及び状態を、Notebookによって制御可能であること
degradedなインフラを、healthyにすることができるNotebookが定義されている等
tech / non-techの間で共有可能なインフラに関する語彙として設定・状態を定義することができれば、XXという設定を行うNotebookや、YYという状態からZZという状態に復帰させるNotebookという形で、tech / non-techで共通の語彙を用いてNotebookを整理することが可能になる。
何か手順を再利用するなんて場合にも、ひとつひとつのコマンド、汎用的なコマンドが主役ではなくて、意図した副作用を生成する一連のまとまりが主題です。 #Narrative_Stories