NPStudy #12の資料です。

1. ＠NPStudy ＃12
｢自動化と画面｣を考えてみました

2. 今日のはなし
物理環境のテストの自動化みたいなことをしていますが､
その過程で出てきた『自動化』と『画面』の話です。

3. 今日のはなし
途中で作ったものをデモしますが、
『それなら良いOSSがもうあるよ』
『こういうのいれるといいよ』
とかあったらぜひ教えてください。
自分で作らなくていいほうがずっと楽だからです。

4. あらまし
今こんなことをしています。
NPStudy #9 ｢OpenVNet｣ (→自動テストに応用してます)
NPStudy #11 ｢NetTester｣
要するに物理ネットワークを含んだインフラの運用でもきちんと
テストして本番反映できるようにしようという活動と､
そのための足りない部品づくりなどです｡

5. なぜこんなことを？
要約するとこんな感じです。
お客さま
『NWに手を加えたいけどテストする時間も環境もないし､
レビューを沢山してぶっつけ本番で設定反映するしかなくてつらい｡』
『テストできる環境があってもパターン多すぎて無理｡
変更あったからすぐ何回もやってとか言われたらもう死ぬ｡』

6. なぜこんなことを？
ぼく達
『物理を含んだ運用でも､開発のように継続してテストして､リリース
サイクルを短くしてリスクを減らす方法がないか考えましょう｡』
『技術は進歩してますし､テスト環境の準備も機械に任せることが
できるかもしれません｡機械は素早くミスの無い刺身たんぽぽが
得意なので､開発同様それをテストに使えないでしょうか｡
(人間介在によるリスクの除去と高速化)

7. なぜこんなことを？
『我々は働くために生きるのではないことを思い出すべきです｡』

8. 目標として、
そのうち皆こんなふうになるといいなと思いながら活動しています。
1
変更
自動テスト
リリース
本番
環境
検証
環境
運用者
機械的に解釈
できる
構成管理
要
件
テストパス後
設定反映
自動構成
自動テストOFS
NetTester
変更後の
テスト
シナリオ

9. といったところで、
運用改善の過程で道具の例としてNetTesterとかを説明してみると
お客さま『我々プログラム書けないんだけど画面とかないの？』
ぼく達『』

10. もうすこし例をあげると、
ぼく達『Terraform Templateでテスト環境を』
お客さま『厳しいですなあ』
ぼく達『じ､JSON』
お客さま『もう一声！！』
ぼく達『』

11. プログラムといえば
『これからの運用者はコード書けなければ淘汰される』
この言葉を時々みかけますが､
コーディングも自動化も手段であって目的ではないはずです。

12. なんのため？
運用改善に機械処理が有効そうだから試すわけです。
諸々うまく回していけるなら何でもいいんじゃないのと思います｡
それを画面でカバーできるならそれでもいいのではと思いました。

13. ちなみに
設定画面は手順書で手運用する方にはとても好まれるIFですが、
自動化マンからは自動化阻害要因として害虫並に嫌われるようです。

14. つまり、
画面としてしか使えない画面では､今までと何も変わりません。
応用が効かないので画面滅べと言われ続けるわけです。
なにより､作っててつまらなそうなのが致命的です。

15. そこで、
今はコーディングしないけどコーディングが必要なプロセスを経ると
運用改善できる可能性がある､という理由があったので､
それを補助できる画面であればいいのかと思いました。

16. ということで、
コードに慣れていらなくなったら捨ててもいい画面もどきを目指して､
現時点でコードを書かない部分を補うものを作り始めました。

17. 余談
『画面は自動化できないから要らない､画面滅べ』
『プログラミングできない運用者は滅べ』
『運用に難しいプログラム強要する仕組み滅べ』
という不毛な争いの話ではなく､
『スケールしない仕組み(手でいじるしかない画面とか)は滅ぶべき』
『(導入､学習コスト共に)異常に難しい仕組みは滅ぶべき』
なのだと思います｡ハードルがあるなら下げるか除去すべきです。

18. 運用自動化の素
ところで､運用自動化の素は何でしょう？
結局のところそれは構成情報ではないかと考えました。
この構成情報を色々な手段でIOして保持する・それを使って何かする
(codeを生成するとか)､ができるものがあって､そこにIOの１つとして
画面の皮を被せればいいんじゃないかと考えました。

19. 絵にすると
こうなってればいいのかなということで、
コーディングが
苦手な人向け
履歴管理が得意
とくにコード類
機械を酷使する系
(NetTester とか Ansible とか )
IO
code(text)
IO
運用する人
色々な IO と
構成情報
IO
code
(text)
IO
operation
(config, etc)
画面もういらない
最初からいらない
人の代わりに

20. 今回は、
この部分があればよさそうです。
コーディングが
苦手な人向け
履歴管理が得意
とくにコード類
機械を酷使する系
(NetTester とか Ansible とか )
IO
code(text)
IO
運用する人
色々な IO と
構成情報
IO
code
(text)
IO
operation
(config, etc)
画面もういらない
最初からいらない
人の代わりに

21. ちょっとだけデモをします
時間過ぎてるかもしれません､すみません。

22. 実はすでに沢山ありますね！
同じ使い方も出来るものは沢山ありますよね(よく調べてないです)。
Horizon+NeutronとかODLなんかが近い例だと思います。

23. そういえば、
前のスライドで思い出しましたが､重厚で､幅広い標準化仕様に対応し､
全てを支配する神のような優れた基盤は結構ある気がします。
みんなこういうの簡単に導入できるのですごいなと思いました。

24. 神基盤
使わ(え)なかった理由は単純なスキル不足です｡難しいです。
もっとスキルがあればお客さんにも提案できたかもしれない…。
どれくらい運用改善に貢献するものかわからなかったので､
すみませんどなたか教えてください｡
効果が絶大であれば最高です､さすが神基盤だと思います。

25. 立ち戻って､
今要る道具はテスト自動化のコーディング補助なので､
それに合ったツールを作ろうと思いました。
ぱっと見できる事が多すぎると何もかもが難しそう､理解が遠のきそう
と感じたからです｡

26. これらを踏まえて、
▷ 機能は少なく明確(構成情報出し入れ､それで何かするの２つだけ)
▷ インストールが簡単(シングルバイナリDLして実行する程度)
▷ ちょっと端っこで試してみる､捨てるが簡単にできる
▷ 何かが得意なもの(バージョニング=gitとか)と組み合わせられる
な､自分でも理解できるレベルの､機械処理に特化した小さいクライア
ントツール(GUIもIOの１つ)があるといいのかなと思いました。
今回の目的として､テストができれば十分なので､そこをターゲットに｡

27. こんど自動テストのデモをします
今日は時間がなくてしませんでしたが､利用の例として:
画面からデザインしたインフラを作ってテストを流すデモを、
５月１２日にWakame Users Groupというイベントでやります。
お時間があればぜひどうぞ。

28. この後どうするの
draw.io(https://github.com/jgraph/draw.io)などに使われる
mxGraphなどを使ってダイアグラムとのIOをつけようと思います。

29. なんのために？
こういう情報をそのまま機械処理にも使えるといいなと思っています｡
.vsdが開けなかったりpdfを見て作業するのが辛いからです。

30. おまけ
ソースはこちらです。
https://github.com/qb0C80aE/clay (本体)
https://github.com/qb0C80aE/loam (モデルモジュール)
https://github.com/qb0C80aE/pottery (画面モジュール)
機能追加はできるだけ既存のコピペで済むように作っています。
なぜなら機能追加するときに自分が楽だからです。

31. Thank you.