てくなべ (tekunabe)

ansible / network automation / 学習メモ

JANOG41で「勉強会のフィードバックから得られた自動化への壁」という発表をしてきました

■ はじめに

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追記)


■ 詳細

詳細はtwitterモーメントととしてまとめさせていただきました。実況ツイートありがとうございました。

twitter.com


■ まとめ

自動化の対象を検討するうえで、リスクや効果といった軸が見えてきました。 リスクが少なく効果が高い「地味に効く」ような自動化も意外とありそうな気もしてきました。 また、ひとくちに確認といっても、立場や考え方によって何を指すかが異なることもあるようなので、会話や議論する際は少々注意が必要と思いました。

この度は発表や貴重なディスカッションの場をいただき、誠にありがとうございました。