SSMJP-20200221-NLOG2N2

自動化完全に理解した(公開版) @nlog2n2 Sekiguchi Toshihiro 2020/2/21 1

今日話すこと 1. 2. 3. 4. 5. 6. 過去の自動化事例（非公開） 自動化の効果 自動化の導入（一部非公開） 継続的なメンテナス（一部非公開） まとめ 次回予告 2020/2/21 2

１．過去の自動化事例 2020/2/21 3

２．自動化の効果 2020/2/21 4

利点と欠点 • 欠点 • 利点 • インフラ構築のテスト工数は明らかに減少する。 • システムの構築だけに目的を絞ると費用対効果が悪い。 極端に同じ作業を繰り返すパターンのみに使える。 • 回帰テスト、デグレート検証には効果は抜群。 • 組織で技術力が一定でないと、メンテナンスが不可能。 大きい組織ほど組織が細分化されているため、大企業 での運用には向かない。 • 開発者とQAで不具合再現手順の共有に使える。 • 新メンバーに構築手順を共有できる。 • 自動化する過程で障害をパターン化することになる。 その結果、障害対応は定型作業になり、障害対応時間 を短縮できた。 2020/2/21 • 物理的かつ論理的に接続されている必要がある。 オンプレや遠隔のネットワーク機器は自動化しにくい。 • 不十分な監視環境、運用ネットワークへの理解がない 組織だと、そもそも自動化しにくい。 • 自動化の仕組みを作っただけでは採用されない。 逆に既定路線として自動化しろと言われることがある。 5

３．自動化の導入 2020/2/21 6

自動化の導入 • 導入しやすいシチュエーション • 導入しにくいシチュエーション • ドキュメントや手順が固まっている組織では、手作業 から解放される恩恵があるとし承認されやすい傾向。 • 人月商売（SIerやSES)では自動化するより属人化した 方が売り上げがあるという理由で却下される。 • 障害対応で逼迫したシステムでは、事業インパクトが 強すぎるとして、自動化対象となりやすい。 • 技術的に詳しくない人が承認する場合、仕組みが理解 できず採用されない傾向にある。 • 超短納期デリバリーが必要な状況では、デリバリー能 力向上のため自動化導入の承認がされやすい。 • 自社製品を抱えている組織では、デグレート検証を効 率化するためにテストを自動化する傾向にある。 2020/2/21 7

４．継続的なメンテナス 2020/2/21 8

継続的なメンテナンスはほぼ不可能 • メンテナンス不可能な理由（スクリプトは吐き捨てるもの！） • • • • いつメンテナンスすればよいかの最適解が存在しない 大きい組織だと個々の技術レベルにバラつきがあり引継ぎが不可能 主要メンバーの退職を起因として自動化の仕組みがメンテナンスされなくなる 協力会社を多く使っている会社は人の入れ替わりが激しく教育してもすぐいなくなる 2020/2/21 9

運用の自動化とは 1. システムの構成を理解し、プログラムを書くというのは、 かなりソフトウェアエンジニアとしてかなり高度なことをやっている。 2. それゆえ、普通の保守・運用メンバーでは引継不可。 3. 引継ぎできなかったプログラムは誰にもメンテナンスされずひっそりと生き続ける。 4. そしてシステムの構成が変更されるか、人為構成が変更されたタイミングで死を迎え るが、それでも内容を理解してない人たちが使い続ける（運用自動化のゾンビ化） 5. 障害が多発するが現場は理解していない。その時には担当者は退職してたりする。 6. それでも自動化した仕組みだけは生き続け、運用におけるオーパーツが生まれる。 2020/2/21 10

５．まとめ 2020/2/21 11

所感とこれからの自動化 • 所感 1. 目的や効果を見定めて自動化したほうがよい。 自動化の本質は、品質の向上やデリバリー能力の向上。 2. 設計方式、運用方式、デリバリー方式の決まっていないインフラ自動化ダメ絶対。 3. 自動化の恩恵を受ける期間以外は自動化を捨てる勇気が必要。 4. テストの自動化はよい。特にソフトウェア開発における自動化は非常によい。 定常的にやることでデグレートを減らせられる。 • これからの自動化（ほかの勉強会で参考になったもの） • Kubernetes どのような状態でありたいかを定義し、常にその状態を維持する。 https://speakerdeck.com/masayaaoyama/jtf2019-k8s-amsy810 • syzkalle/syzbot Linux kernel のファジングするツール。 不具合の発見、報告、再現方法のコードの生成までを自動化している。 https://speakerdeck.com/fujiihda/linux-kernel-fuzzing-tool-syzkaller https://syzkaller.appspot.com/upstream 2020/2/21 12

• https://speakerdeck.com/masayaaoyama/jtf2019-k8s-amsy810
• https://speakerdeck.com/fujiihda/linux-kernel-fuzzing-tool-syzkaller
• https://syzkaller.appspot.com/upstream

スペシャルサンクス • 以下の素材やスライドデザインを参考にしました。 • プレゼンテーション用アイコン（yuyarinさん） https://github.com/yuyarin/presentation_icons • 運用自動化、不都合な真実（波田野さん） https://speakerdeck.com/opelab/20171212-automation 2020/2/21 13

• https://github.com/yuyarin/presentation_icons
• https://speakerdeck.com/opelab/20171212-automation

６．次回予告 リクエストを受け付けます 2020/2/21 14

次、発表するかもしれないリスト • • • • • • • • • • • • • 私の退職理由 4社分（完全非公開予定） やばいバグ曲線LT 自動化マシンの配置LT 非機能要件の使い方（非公開予定） リリース判定のタイムアタックについて 監視ポイントとNWセグメントの話 会議でスマートに見せる100の方法を読んだ感想 胆石症 長野県に移住失敗した話 今まであったヤバイ10選（非公開予定） 過去に好きだったゲームの話 バグ報告書の書き方LT 手順書の書き方LT 2020/2/21 88 21 52 終わり 15