てくなべ (tekunabe)

ansible / network / automation / StackStorm

JANOG44 レポートその2【登壇編】ここからはじめよう、運用自動化

はじめに

2019/07/24-26 に兵庫県神戸市の神戸国際展示場で開催された JANOG44 Meeting in Kobe に参加、登壇してきました。

本ブログでは、2回に分けてレポートします。

  • その1 参加編
  • その2 登壇編 ここからはじめよう、運用自動化 (本記事)

その2である本記事では、前哨戦として Day2 に開催した野良BoF「運用自動化、どこからはじめる?」と、Day3 の本編「ここからはじめよう、運用自動化」に登壇するまでの経緯や、当日の様子などをまとめます。

f:id:akira6592:20190730104614p:plain:w400
会場の様子。別途サテライト会場も用意していただきました(後述)



■ 経緯

ある意味リベンジ企画

JANOG では、過去にも運用自動化に関連する多数のプログラムがありました。 今回の発表は JANOG42 の「その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜」の流れを組むものです。このプログラムでは私は登壇者ではなく参加者でした。JANOG 42 では、話がネガティブになりがちだったため、JANOG43 ではまた別の話をしようということで、登壇者としてお誘いを頂きました。

当初 JANOG43 では、良い手順書を探るようなプログラムを検討していました。しかし、少々まとめるのが難しくなり、保留になりました。

日をおいて今回の JNAOG44 の準備期間(といっても2月)に入った頃に、検討しはじめ「ここからはじめよう」というテーマにすることにしました。JANOG44 自体のテーマ「The One」にピッタリなのは偶然なのか、合わせたのかは覚えていません・・・。

BoFもやろう

JANOG では、よく BoF というかたちで少人数が集まって話し合う、座談会のような企画もあります。JANOG meeting 自体も meeting なので、意見交換が重要な要素ですが、それよりもっとこじんまりする印象です。

過去にも開催してきた自動化関連の BoF が盛り上がって良かったので、野良BoFというかたちで開催することにしました。



■ Day2 野良BoF「運用自動化、どこからはじめる?」

野良BoFとはいえ、JANOG 用に確保していただいている会場を利用させていただきました。 おかげさまで大勢の方にお越しいただくことができました。

様々な方からご意見をいただきました。感じたのは、体制によって大きく状況が変わるといいうことです。

  • 人が少ないから自分たちで開発も運用もやっている
  • 人が多すぎて、開発と運用を分けざるを得ない
  • コード書ける人のみを採用している
  • トップからの意志で、特定のツールを利用することになる

などなど・・(一部、野良BoFと本編の記憶が混在してるかもしれません)

開催側としての心残りが一点。参加していただいた人数が多く(60人ほどでしょうか)、BoFというより少々セッション形式に寄ってしまいました。そのため、意見を出しにくかった方もいらっしゃったようです。分割するなりの工夫が必要だったのかもしれません。

toggeter



■ Day3 本編「ここからはじめよう、運用自動化」

概要

ここからはじめよう、運用自動化 :: janog44

9/2(月)の正午頃までの動画アーカイブ配信もあります。

資料

toggeter

流れ

金子さんからのイントロダクション、登壇者紹介のあと、なぜ自動化する必要があるのかを、社会情勢を含めて波田野さんから解説。

その後、3つの仮想ロールとして、それぞれが、どのように始めればよいかを、提示持していきました。運用責任者を波田野さん、現場に近い運用リーダーを私、その間に挟まれる運用マネージャーを長久さん、という順番で発表しました。

なぜ運用自動化が必要か

資料: 2019-07-26 なぜ運用自動化が必要なのか/20190726-why-need-operation-automation - Speaker Deck

生産人口が減少する一方で、業務が増えていく状況においては、業務をスリム化し、人がやる必要のない業務は自動化することが求められる。というお話。

途中、「30代後半から体力激減」という話があり、ドキッとしました。

各ロールごとの話

運用責任者として

資料: 運用責任者が最初にやるべきこと /20190726-janog44-start-operation-automation-guide - Speaker Deck

まずは、業務範囲、コアコンピタンスを明確化し、「人がやる業務」と「機械がやる業務」の分離をする必要がある。というお話。

P35 あたりで「公式サービス」「非公式サービス」という言葉ができます。これは、運用メンバー寄りの立場であっても、アピールできるものか、そうでもないものかを考える上で、意識したほうが良い観点だと思います。

運用リーダーとして: はじめどころを探る自動化アセスメント

資料: はじめどころを探る自動化アセスメント(JANOG44 ここからはじめよう、運用自動化)

私のパートです。思いつきで自動化対象作業の優先度を決めないように自動化のはじめどころを探る、自動化アセスメントの考え方をご紹介しました。

各スライドの内容を簡単におさらいします。

分類と観点を洗い出してからアセスメントする

自動化対象の優先順位を決めるときに、たとえば「小さなことから」とした場合、某異彩事を指しているのでしょうか。実装に掛かりそうな時間でしょうか、リスクが少ないところでしょうか。「小さなことから」と仮定しただけでも、このように考えていくと観点の偏りやモレが発生しそそうと感じました。そのため、これらの観点を一段抽象化した分類から考えてみます。分類してから該当する観点を洗い出し、各作業をスコアリングし、スコア計算値の高い作業が優先度が高いと決められるのではと考えました。

今回これを自動化アセスメントと呼ぶことにしました。

観点の分類

分類を考えるための軸は2つ。 1つめの軸は、自動化前・後。自動化前の観点は、自動化すること自身に対する観点。例えば、実装の難易度などです。自動化後の観点は、自動化したシステムがもたらすものに対する観点。例えば、見込まれる影響度などです。

2つめの軸は、大小の価値観です。大きいほうが優先の観点、小さい方が優先の観点、それぞれあります。

4つの分類

https://image.slidesharecdn.com/janog44startautoyokochiomiyage-190729010448/95/janog44-14-638.jpg

  • 【動機】自動化に対するもの(自動化前)で、大きいほうが優先の観点
    • 現状脅かされているQCD、かかっている精神・身体負荷など
  • 【抵抗】自動化に対するもの(自動化前)で、小さいほうが優先の観点
    • 実装難易度、想定コストなど
  • 【リターン】自動化がもたらすもの(自動化後)で、大きいほうが優先の観点
    • 見込まれるQCDの向上、精神・身体負荷の改善など
  • 【リスク】自動化がもたらすもの(自動化後)で、小さいほうが優先の観点
    • 影響度、運用難易度、過剰な人員削減

観点の洗い出し

考えた分類に対して、どのような観点があるか洗い出していきます。 今回ご紹介した分類や観点はあくまでも例なので、実際の業務に合わせるには、分類や観点をカスタマイズしたり、重み付けを設定したりする必要があります。

また、自動化アセスメントを関係者一同でおこなうことで、自チームだけでは見えない観点が見えてくることも期待できると考えました。

運用マネージャーとして

資料: janog44_190717_nagaku.pptx - Google ドライブ

運用マネージャーは、トップダウンボトムアップを結んだり、チームを作ったり重要な役割。自身もエンジニアとして現場に出た場合、 3ヶ月で追いつけるぐらいの距離は保つために勉強しておくのが大切。というお話。

紹介されている「LeanとDevOpsの科学」という本は私も読んだことがあります。「デプロイ負荷」の考え方は、私の発表の自動化優先度の観点のヒントにさせていただきました。

ディスカッションタイム

作業の優先度を決めるのより先に必要なこと

ディスカッションで、印象的だったのが「順番を間違えると大変なことになる」というコメントでした。

マネジメントロール主導より、現場メンバー主導のほうが良いのでは。メンバーがやりたいと思う自発性、「これやれるんじゃないか」「ちょっとやってみました」のようなところが、一番始めるきっかけきになるのでは。マネージャーは、褒めたり、メンバーからの声をあげる機会を増やすほうが需要では。スキルを底上げする、現場のモチベーションをあげる、キープする、やりたいと思えるメンバーを増やすのがキモ。優先度を決めるのよりも先では。

私も現場主導でというのは、チームビルディングの一環と捉えて賛成しています。 私の今回の考え方の中では「動機」という分類のところに、メンバーの気持ちを含めたつもりでした。ですが、順番まではうまく考えられていなかった気がします。作業にフォーカスしすぎて、あまり人にフォーカスできていませんでした。

他にも、様々な立場の方から質問、コメントを頂きました。詳細は togetter をご確認ください。悩み方、解釈の仕方なども、置かれている立場によって変わるのだなと感じました。

こっそり考えていたこと

今回、アセスメントの作業の例として「ルーティング追加」「状態確認」「ACL変更」のような物をあげました。 これらはすべてネットワーク機器へ接続が必要な作業です。

そういう意味ではもししかして、機器に接続するために必要な構成管理情報(IPアドレス、認証情報など)の整理が先ではないかとも思いました。

なので、作業のなかにも「これを先にやらないとどうやっても先に勧めなれない」ような、土台、レイヤーのようなものもあるかも、とこっそり考えていました。

【謝辞】臨時サテライト会場のご用意ありがとうございました

大勢の方にご参加いただき、関心の高さと熱量を感じました。 立ち見が出始めた頃に「座ってもらいたいが椅子は場所をとってしまい、人が多く入れなくなる。とはいえ、80分プログラムで立ち見は負担が大きい。」という難しい状況の中、椅子を追加しつつ、別フロアにストリーミングを映し出すサテライト会場を臨時で用意、という対応をしていたきました。このことはあとで知ったのですが、スタッフの的確な判断と、対応の速さにただただ感謝するばかりです。本当にありがとうございました。



■ 登壇編のまとめ

3つのロールに分けてそれぞれの考えを提示するという本プログラム。この企画を準備の段階でさまざまな意見交換をしてきました。当日も様々な立場の方から、ご質問やコメントを頂きました。これらにより、私なりに視野を広げることができた気がします。

これまで、私自身も JANOG41のネットワーク運用自動化BoF、JANOG42のAnsible ネットワーク自動化チュートリアル、JANOG43の自動化の行き着く先は?、そして今回、と立て続けに自動化関連のプログラムで登壇させていただきました。ありがとうございました。 毎回、一定の関心の高さが伺えるため、今後も何かしらの切り口で運用自動化のプログラムがあり、意見交換ができると良いなと思いました。

スタッフみなさま、マイクに立っていただいたみなさま、ご参加頂いたみなさま、企画立ち上げ時に引っ張ってくださった今井さん、臨時でまとめ役をご担当いただいた金子さん、各ロールを演じてくださった波田野さん、長久さん、ありがとうございました!