2015年1月4日日曜日

ChefやAnsibleを使うときに気をつけておきたいこと

前の記事で、書きそびれていたので、続き。


主にチーム体制に関する内容で、Chef/Ansibleに関するノウハウではありません。


チームメンバーも触れるようにしておくこと

保守や引き継ぎの難易度を上げる要素の一つが、誰でも触れるのか?という点だと思う。
具体的に言うと、本番の環境とは切り離された、独立した開発環境があり、かつ、
複数人の人が操作方法を知っている、やったことがある、といったこと。

開発当初は直接サーバ上でやってたりして、環境が分かれていないケースがあったりすると思うし、
誰かの環境からでないとデプロイできない環境というのは割と 多いと思う。
けど、やがて煙が立って炎上していくというのは、多くの人が経験したり、させたりしてるんじゃないかな。

ChefやAnsibleでも、同じような話を聞くことが何度かあった。
おそらく共通しているのは、他に触れる人がいない脆弱なチーム体制なんだと思う。
インフラは任せっきりで、何がどうなっているか、その人が辞めて初めて、把握してないことに気がつく。
結構クリティカルだと思う。


やってみようという努力

じゃあ、それが誰のせいなのか?前任者?チーム?
自分はチームとその人の両方の責任だと思う。


実は、READMEを見れば、sandbox的な環境での試し方(Vagrantでとか)、
ServerSpecで期待通りになっているかの確認方法とか書いてあるのに、見落としているかもしれない。
その人がどういう性格や思考の人で、どういうスタイルでやってたか、だいたいわかってればこの辺はクリアできると思う。
わかっていなければ、コミュニケーションや情報共有不足というチームとその人との関わりに問題があったのだと思う。

この人がいなくなるとまずいという危機意識は健全だと思うので、
インフラをやらない人でも、Chef/Ansibleに興味を持つことは良いことだし、
時折、どうやっているか聞いたりすればいいんじゃないかな。
そこで、実は本番で直接やっているとか、その人にしか触れない環境があったりすれば、
それがリスクが高いということには気がつくだろうし、
後になればなるほど技術的負債になる可能性も高くなるかもしれない。


コミュニケーションしないと生まれないものがある


インフラに限ったことじゃないけど、継承されにくいものというのは、明文化ができてないのではないかと思う。
その人が個人事業主で一人でやってるのならいいけど、その人とともに失われるものが多いと、組織としてはまずいはず。
ソフトウェアは芸術作品のように完成して終わりということがほぼないため、保守開発という工程がある。
そういった場合に職人芸であっては困るはず。

なので、ドキュメントを書くのだけど...
ドキュメントを読んだ人はちゃんとフィードバックしているだろうか?
大人になると怒られるのは嫌だし、そもそもバカだなんて思われたくはないけど、
誰でもわかりやすいドキュメントを書けるとは限らないのだし、
良いドキュメントを書くスキルを身につようとしている途中かもしれない。

「ドキュメントは誰にでもわかりやすく」と漠然としたことを平気で言う人もいるけど、
「日本語を母国語として、中学校卒業レベルの学力を有する人」という人を前提に、
チーム内で読まれるべきドキュメントを書く人なんているだろうか?
そんな時間があるんだろうか?

チームのドキュメントはチーム内のメンバーが読んでフィードバックしないと良くならないと思う。
どこまで書くべきなのか、何か不足していないか、
ドキュメントの問題ではなくチーム内で勉強会をして底上げする方がいいんじゃないかなど、
チームのレベルに合ったドキュメント作りは、フィードバックと周りのサポートがあってこそできると思う。
それがなくてもドキュメントを書ける人がいるかもしれないけど見かけたことはない。
ドキュメントを読まなくても、できるケースはあるけど。


個人的に、ドキュメントは簡潔な方がありがたいので、少ない方が嬉しい。
そのために、省略できるものは省略すべき。
省略するためには、チーム全体の知識や経験を増やす必要が出てくる。
ので、誰でも触れる環境がある必要があるし、実際に触らせることも大事だと思う。
それが言いたかった!


次は、また書きたい欲が溜まればCSSについて書くかもしれない。

0 件のコメント: