日時: | 2017-07-04 |
---|---|
作: | @voluntas |
バージョン: | 1.0.2 |
url: | https://voluntas.github.io/ |
時間: | 30 分 |
この資料は 2017-07-03 に行われた Tech Night @ Shiodome # 4 - connpass の 発表者メモ です。
ショートURL は http://bit.ly/atarimaenokoto です。あたりまえのこと、です。
時雨堂という会社で Erlang/OTP という言語でミドルウェアを書いてご飯を食べています。専門はプロトコル的に認証、課金、暗号です、最近はここにリアルタイムな音声や映像配信が追加されました。
たまに技術コンサルタントとしてインフラよりの部分での改善をお手伝いしたりしています。
DevOps って言葉はキライなので、使いません。今日は自動化の話をします。ただし、自分は運用経験は皆無です。では何の話をするのかというとミドルウェア開発者視点で見た自動化の話をします。
自動化は実際に手を動かして行ったこともありますが、基本的には方針を決めるのが主な仕事です。いろいろなところでお手伝いしたりしています。
ちなみに今日発表する内容はあくまで、私個人の意見であり、世間一般的な話ではありません。色々なところでお手伝いした経験や、自分で開発やメンテンナンスをしてきた話です。
自動化は多種多様で銀の弾丸はありません。組織、業務、製品、文化、その他、色々な条件が複合的に絡み合っています。今までこうやってきた、これでうまく言ってきたんだ、こうすればいい、なんてありません。そう言い出したらその人の話は無視しましょう。
本日はインフラよりの自動化の話をして行きたいと思います。ただ自動化で幸せになるという話ではありませんし、技術的な話もほとんどしません。
ではどんな話をするのかというと、自動化をすすめる時に、何をやればいいのかという話です。
自動化と聞いて何が浮かびますか。殆どの方は自動デプロイだったり自動ビルド、自動テスト、このあたりでしょうか。ちょっとマニアックな人だと自動ロードテストとか。あとは自動で API が生成されたり、ドキュメントが生成されたり。色々ありますね。
では実際に自動化できてる会社ってどのくらいあるんでしょうか。自分がお手伝いする所は これからやっていきたい という会社なので、もちろんやっていない場合がほとんどです。
弊社は小さな会社なのでフットワークは軽いのと、自社製品ということで自動化やっていますが、全体の 50% 程度です。それ以外は残念ながら手動です。
殆どの場合は、同じことの繰り返しがめんどくさいからだと思います。あとは手動でやる場合だと手順が人それぞれで違う場合が多かったりとか。
自動化の目的の一つにドキュメントを減らしたいから、というのはあるような気がします。つまり自動化は動くドキュメントとも捉えられると思います。この時点でなにやらプログラマブルな話に気づいた方がいらしゃったらその人は大変自動化に向いていると思います。
残念な理由としては自動化することでコストを減らせるため、というのが経営者だとあるかもしれません。ただ残念ながら自動化でコストが下がることはよほどじゃないかぎりはありません。自分は自動化はコストが上がると考えています。
答えは単純です、自動化は恩恵を受ける側からするとブラックボックスそのものです。よくわからないけどなんだかうまいことやってくれている。ということです。つまりそのブラックボックス自体を面倒見るコストが発生します。
ブラックボックスを面倒見るコストはとても高いです。技術は色々でてきますし、自動化の要望は無限です。それに対応していくには自動化自体の改善、開発、メンテ、時には作り直しなどが発生します。
これがコストです。そしてこのコストを払わないと、自動化が手動時よりヒドイ、何がなんだかわからないことになっていき、本当にヒドイことになっていきます。
経営層側の人は、自動化はコストが上がるというのを認識するべきです。
私は自動化というコストを払って様々な点での効率を良くすること、だと考えています。
効率が良くなるというのはなんでしょうか。
例えばデプロイ作業が 1 時間から 10 分に変わったは効率が良くなる事だと思います。他にも開発サービスで利用しているライブラリのアップデートがテストやビルドを自動化していたことにより、簡単にアップデートできたも効率が良くなるだとおもいます。
ここからは自動化、というよりは自動化をするまえにやるべきことをお話していきます。
いきなり自動化を導入したとしても、うまくいくことはありません。自動化は順を追って導入するものです。そして自動化がある文化というのを作っていくべきだと考えています。
さて、文化という話をしたら負けという話がありますが、私はそう思っていません。自動化する文化というのはとても大事だと思います。
文化という抽象的な単語で誤魔化そうとしているわけではありません。ここで言っている文化は皆が自動化は大事で、自動化はするべき。そして自動化にはコストがかかるという感覚を共有している事、としておきます。そんな簡単な話ではありませんけどね。
私がお手伝いをさせて頂く時に、これはやったほうがいいと思う、と提案するのが4つあります。その話を最後にさせていただきます。
ここでの資料という定義は困ったり、迷ったりしたときに参考にできる資料です。普段は見なくていいやつです。
自動化を行う場合の方針やルール。つまり決まりごとをドキュメントに起こしてもらうようにしています。特にフローは重要です。
行き当たりばったりではなく、こんな時はどうする?というその会社独自のものを担当者に作って貰うようにしています。明文化ですね。
基本は細かいルールではなく、大まかなルールです。ただし運用寄りの場合はかなり細く決めてもらいます。そしてその細かいルールを自動で実現できるような仕組みを作り込んでいったり、という場合もあります。
これがないと、勢いだけになります。自動化は長く終わりのない戦いです。そのためにも資料もアップデートしていく必要があります。
バージョン管理された資料の大切さをこの資料で学べます。フォルダ管理ではだめですよ。
レビュー、皆さんよくやっていると思います。やっていないなら、やりましょう。
さて、レビューの導入と言いますが、ここでのレビューはバージョン管理ツールがある前提でのお話です。つまり差分が気軽にみれる前提ですね。
変更をして、レビュー依頼を出して、レビューされて、指摘場所を修正して、レビューされて ... 最後にマージします。このフローです。
レビューはすごく大変です。めんどくさい上に、社内に年寄りが偉い文化とかあるとうまく行きません。気を使ったりしたらもうダメです。妥協は崩壊の始まりです。
レビューというのはやってもやらなくてもバレにくいです。結局個人のモラルが重要になってきます。どうやってレビューがある文化を維持するかというのも課題の一つです。組織によって方法は違うでしょうからその話はここではしません。
ちなみにお手伝いした会社の一つでは、レビュー担当者をすべて新人にするという方法を取ってみたことがあります。先輩方は新人のレビューが通らないと、マージできないという仕組みです。これはうまく回ったという話を聞いています。LT でこの話の続きが聞けるかもしれません。
期待しておきましょう。
これは、強制ではありません。ただお勧めはしています。自動化を導入する以上、バージョン管理は必須です。 そのリポジトリごとの README 、つまり使い方や紹介、運用方法などが書いてあるものを用意しましょうという話です。
さらには CHANGES 、つまり変更履歴ですね。これも書ける範囲で書いていきましょう。このあとのバージョニングの話にも影響しますが、そのバージョンでどんな変更が入ったのかを CHANGES だけで把握できるのはとても大きです。もちろんコミットログを追いかければわかりますが、効率は悪いです。
また、人に伝える能力や、まとめる能力は README や CHANGES を書くことで学べます。アップデートをこまめにするというのも。
以外に皆さん適当にバージョン番号をつけていることが多いです。自動化を行う際、実はバージョニングも重要な要素なのです。 どんなバージョンの付け方にしていくのか、バージョニングはリリースとも密接に関係していきます。
なんとなくで決めずにしっかり決めましょう。
自動化の話といいつつ、自動化を導入するための話をさせていただきました。話を聞いてどう感じましたか?当たり前の話に聞こえた方が多いと思います。そうなんです、当たり前の話をさせていただきました。
当たり前なのにやっていない場合が異常に多いんですよね。あたりまえをあたりまえのようにやることの難しさが自動化の最大の敵です。
敵はいろいろなところに隠れています。「あたりまえだろ」と思い込むのも的です。その瞬間ではだめなのです。あたりまえを継続し続けることに自動化の勝ちはあるのです。
今回話しをしなかった部分
時間がたりなかったのでテストの話は割愛しました。
そもそもテストは品質を向上させません。品質を確認するものです。私はテストの専門家ではないので、テストについては、t_wada さんというテストの神様の資料を置いておきますので、是非見てみてください。