はじめに
2019/01/23-25 に山梨県甲府市のコラニー文化ホール(山梨県立県民文化ホール)で開催された JANOG43 Meeting in Yamanashi に参加してきました。(ハッカソンは1/22)
本ブログでは、3回に分けてレポートします。
- その1 参加編
- その2 登壇編 自動化の行き着く先は?(本記事)
- その3 ハッカソン編
その2である本記事では、「自動化の行き着く先は?」に登壇するまでの経緯や準備、当日の様子などををまとめます。
■ 経緯と準備
答えがなく、悩ましい話題
JANOG43 のプログラム公開後、登壇者である後藤さんからお誘いいただき、後から追加で入れさせていただきました。プログラム委員の方々調整ありがとうございました。
普段扱っている Ansible などのツールの話ではないため、正直どのような観点でお話するか悩みました。後藤さんからのドラフトのスライドを拝見すると、運用の価値や運用自動化の目的についての問いかけがいくつかありました。
そのため、プログラム後半の参加者含めたディスカッションのきっかけとなるような、一つの意見を述べるかたちにしました。ただ、言語化は難しかったです。読むと当たり前のように感じる言葉でも、実際自分で書くとなるなかなかですね・・。
■ 発表
アーカイブ配信 (2019/02/28 12:59 まで)
資料
togetter まとめ
- #JANOG 43 Meeting Day 2 午前 (3ページ目) - Togetter
- 2019-01-24 11:22:20 のツイート以降
■ ディスカッション
ツイートをピックアップさせていただきます。ツイートありがとうございました。
(長久さん)
— HATANO Hirokazu (@tcsh) 2019年1月24日
手順書書く人と使う人が別れているケースが多いが、うちではそれではまわらない。
うちでは、全員がエース級であることを期待して、自分達で手順書を書いて共有しながら運用している。
自動化と手順書はセットで考えるべき話なので、すごくわかります。
#janog43_room
手順書をつくるメンバーとそれを使うメンバーが違う
— botisle (@hi86074659) 2019年1月24日
NIIはこれが同じメンバーで手順書の内容以上がわかっている
そう、NIIさんのJupyter Notebook の使い方と自分で違うのは
叩くコマンドを修正させない、見せない ってところですね#janog
そもそも、スケールさせるため(サービスを継続させるため)には運用自動化は必須#janog
— botisle (@hi86074659) 2019年1月24日
自分としては、求められるサービスを実現するために
— botisle (@hi86074659) 2019年1月24日
複雑性・抽象性が上がってくるのは間違いなく
機器にログインしてコマンドを叩く ってのはレアケースになってくる
と思います(近い将来)。#janog
「自動化しなくてまわっているところは、自動化しなくてもいいんじゃないか」
— HATANO Hirokazu (@tcsh) 2019年1月24日
その通りだと自分もおもいます (イイネ 100)
#janog43_room
規模は質問者の方よりも若干小さいですが、「自動化しないと死ぬ」経験あります。
— HATANO Hirokazu (@tcsh) 2019年1月24日
が、そのまま自動化していくと結局死ぬのが、長久さんと自分の経験なので、どうなのかなーとは思います。
やはり、やりようかなと思いますです。
#janog43_room
#janog #janog43_room 「あえて自動化しない」歴史的経緯やしがらみやライフサイクルを考慮した場合、レガシーなやり方で逃げ切った方が良いビジネスもあるし、先日も、相談頂いた際に、逃げ切りを提案したことはあります。
— 長久 勝 (@mnagaku) 2019年1月24日
ハッカソン参加率を増やすには?
— botisle (@hi86074659) 2019年1月24日
自由にやらせるべきだけど、参加者(参加企業)にメリットを与える
ある程度の強制力的なものが働けば ね
質問が出ない時に人を指名してしまう的なやつ#janog
(國武さん) 自分で実装したものは業務に妥当な自動化できるが、他人が実装したものはやはりギャップがある。
— HATANO Hirokazu (@tcsh) 2019年1月24日
そうなんですよね。「現場の状況を忖度」して実装した要素が少しでもあると、現場では使いにくいとか、業務の本質とずれた実装になりがちです。
#janog43_room
「UNIXの考え方」に基づいた、小粒でひとつのことを上手にやるRead型のスクリプトやツールをたくさん作るのはおすすめです。
— HATANO Hirokazu (@tcsh) 2019年1月24日
将来的に一気にテコが効きやすくなるのと、副作用が少ない(Readだから)なので、かなり有効だと思います。
(それを基にレポート作るときは別の検討必要
#janog43_room
「UNIXの考え方」に基づいた、小粒でひとつのことを上手にやるRead型のスクリプトやツールをたくさん作るのはおすすめです。
— HATANO Hirokazu (@tcsh) 2019年1月24日
将来的に一気にテコが効きやすくなるのと、副作用が少ない(Readだから)なので、かなり有効だと思います。
(それを基にレポート作るときは別の検討必要
#janog43_room
togetter まとめ
- #JANOG 43 Meeting Day 2 午前 (4ページ目) - Togetter
- 2019-01-24 11:41:47 のツイート以降
■ 野良BoF
後藤さんの主催で、当日の午後に「運用自動化時代の運用者のあり方とは?」という野良BoFが開催されました。野良BoFとは、JANOG43ミーティング実行委員会が管理、選考を[通常BoF]とは異なり、主催者で管理、運営するタイプのBoFです。「自動化の行き着く先は?」の続き的な位置づけのものなので、私も参加させていただきました。
プログラム本編では出てこなかった、物理作業のつらみの話もありました。
togetter まとめ
- #JANOG 43 Meeting Day 2 午後 - Togetter
- 2019-01-24 13:43:44 のツイート以降
■ まとめ・感想
今回は、自動化の仕組みを作る側と使う側に分かれるとうまくいかず、運用者自体が自動化を作ったほうがよい、という意見が多かったように感じます。
今になって少し疑問になってきたのですが、そもそも分けるとかチームとは何でしょうか。お財布の分け方でしょうか、それとも単純にリーダーとメンバーの体制の単位でしょうか。もしかしたら、仮に作る側のリーダーと使う側のリーダーが同じでも、お財布(予算)が同じだと、また論調が異なってくるものでしょうか。
着地点のない話題ですが、何かしらのヒントや考えるきっかけになったのであれば幸いです。 参加者のみなさま、お誘いいただいた後藤さん、スタッフみなさま、本当にありがとうございました。