■ はじめに
2018/01/24-26 に開催された JANOG41 Meeting のネットワーク運用自動化BoFの枠の中で「勉強会のフィードバックから得られた自動化への壁」というLTをさせていただきました。 この記事では、発表資料の共有と、私なりのディスカッションのおさらいをします。
なお、私が参加したその他のプログラムについては JANOG41 Meeting in Hiroshima 参加メモ をご参照ください。
■ 概要
去年1年間、社内外の勉強会でネットワーク自動化ツールについての発表を数回行いました。頂いたフィードバックなどから自動化への壁を改めて感じましたので、その共有をさせていだきます。また、壁を壊すアイディアや、ほかに感じている課題などありましたら、皆さんからも意見を頂戴したいと思います。
せっかく様々な方が集まる場なので、一方的な情報発信だけではなく、ディスカッション的なことを行いたいと考えていました。
■ 使用した資料
www.slideshare.net
■ ディスカッション
後半に設けたディスカッションの時間で皆様から頂いたご意見を、自分なりに解釈しながらまとめました。
どこから始めたらよい？
確認系
- 手作業の手順書は設定より確認のほうが多い。確認から自動化してみてはどうか
- 手作業がしんどい作業を自動化すると効果的
- 手作業による確認は疲弊しやすい→ミスの元
- サービス正常性確認は自動化に適している
情報取得系
- サポートへ問い合わせする際に必要なログ一式を取得してメール送信まで自動化したら効果があった。手作業だと取得漏れが起きやすい。
割り切り
- 割り切って、失敗しても大丈夫な作業から初めてはどうか
特殊オーダーの難しさ
- 定型オーダー作業は自動化しやすいが、特殊オーダー作業は自動化しにくい
Jupyter Notebook の活用
- Jupyter Notebook で自動化をしている事例がある。
- 過去に利用したNotebookをコピーしてパラメータ変更して再利用するといったことができる
- （参考）Day3 プログラム Literate Computing for Reproducible Infrastructure」
「確認」とは
- 大きく分けて2つ（特に個人的な解釈が入っています）
- サービス正常性確認
- ≒ 監視
- 監視項目は障害が起こるたびに穴をふさぐように増えていく
- 穴のふさぎ方のナレッジが共有されるといいのでは
- 作業の妥当性確認
- 作業が正しく行われ、想定通りの状態になったかを確認する
- 例）OSPFのコストを100から20に変更し、自身と周辺のルーターの show コマンドにより、想定するコストになったかを確認
- サービス正常性確認が正常でも、隠れた想定外設定が入っている場合に後でサービス異常になる可能性がある
- 作業が正しく行われ、想定通りの状態になったかを確認する
- サービス正常性確認
テスト駆動
- テストしながら開発しましょう
- ステージング環境の監視はテストになるのではないか
BoF主催者によるダイジェスト（振り返り） (2018/04/28追記）
- 2018/04/20 に開催されたJANOG41.5 Interim Meetingにて、本BoF主催者による振り返りがありました。
■ 詳細
詳細はtwitterモーメントととしてまとめさせていただきました。実況ツイートありがとうございました。
■ まとめ
自動化の対象を検討するうえで、リスクや効果といった軸が見えてきました。 リスクが少なく効果が高い「地味に効く」ような自動化も意外とありそうな気もしてきました。 また、ひとくちに確認といっても、立場や考え方によって何を指すかが異なることもあるようなので、会話や議論する際は少々注意が必要と思いました。
この度は発表や貴重なディスカッションの場をいただき、誠にありがとうございました。
