現場から見たDevOpsを推進する組織運営 入社5年目の技術者の声から：特集：DevOpsで変わる情シスの未来（2）（2/3 ページ）

[原田美穂，＠IT]

自動化で分かったヒューマンエラーのリスク

　Chefを使った自動化を推進した利点は意外なところにもあったという。徐々に各サービスで利用しているサーバをchefレシピで置き換えていったのだが、「過去、手動でセットアップしていたサーバの中に、極稀にですが、一部の設定が漏れていたものが見つかった」のだという。幸い、セキュリティ上の問題となるものではなかったが、インフラ部門が標準としていた構成から逸脱した設定が発覚、改めて、公式に検証済みのChefレシピを走らせて、無事、同社標準の設定を適用したこともあるという。

　「意外とあったのが、ジョブ自動実行用のcronの設定漏れ。設定漏れそのものに気付きにくいものだったのですが、Chefレシピを使って一定の内容を適用させていくことで、こうしたヒューマンエラーのリスクも減りました」（石川氏）

　500台の仮想マシンのログを監視していたとして、そのうち1台だけ設定が漏れていたとしても、運用後に気付くことは難しい。こうしたヌケ・モレを解消するのにもChefレシピによる管理・運用は役立っているという。

　手動設定のリスクはcronだけではない。Webアプリケーションサーバの設定に不備があり、危険なデフォルト値が残っていれば、最悪の場合はセキュリティ上の穴となり、ユーザー側に被害が及ぶ可能性もある。サービス提供を事業の柱としている場合、こうした問題は事業そのものを揺るがすリスクとなり得る。

品質担保のための方法は

　開発部門でChefのレシピが書けるスキルのある人材はまださほど多くないという。いくらRubyで設定ができるとしても、サーバの細かな設定部分は、やはり、インフラ部門が管轄してきた領域だ。

　一方で、開発部門側は開発部門側で、規定のサーバ設定では実現しにくい実装を行いたい、という場合もある。こうしたケースでは、事前に石川氏のようなインフラ担当者に連絡し、Chefレシピ化を検討してもらった上で、社内公認レシピとして共有してもらう体制が整っている。

　例えば開発側から、「イレギュラーなセットアップをした環境を開発中にどうしても利用したい」という要望が挙げられた場合、インフラ担当側はそれを検証するなりレシピ化する作業を行う。有用なレシピの場合は、インフラ部門共通のレシピへの昇格もある。

　「共通レシピへの昇格は、ごく一部のインフラに深い知識を持つチームが権限を持っている。ここで、品質を担保するようになっているのです」（石川氏）

　この、極限られたインフラ全体への権限を持つチームが、新規要望の設定の安全性検証や、通常メンテナンスの範囲に含まれるOSのバージョンアップやパッチ適用などに必要なレシピも検証し、配布している。

　新規のレシピ設定依頼はBTSなどを使っているわけではなく、「今は開発チームもUIチームも席が近いので、ちょっと口頭で話をしてもらえば、私からすぐにインフラチーム向けに打診できる状態」だという。新しいチャレンジへのハードルは格段に下がっている。

　「サービスにもよりますが、ものによっては数十台から数百台のサーバを使って運用している。これらを個別に、アップデートやパッチ適用などのメンテナンスする工数を考えると、格段に効率化できています」（石川氏）

　そうはいっても、開発部門の一時的な「勝手設定」が致し方ない場面も有り得る。一時的にやむなく実施しているケースもあり、「確認せずにレシピを走らせると、その設定を上書きしてしまうことがあるんですよ（笑）。だからこそ、コミュニケーションは重要になります」（石川氏）。

開発、テスト、運用の関係はどう変わったか

サイバーエージェントが展開するサービスの一例。コンシューマ向けサービスであることから提供速度とともに高い品質も求められる

　DevOps的な開発体制では、開発部門・テスト部門・運用部門の連携をいかに実現するかが課題となる。素早いサービス立ち上げに向けて、この部門関連系を推進するツール類も出揃ってきている。

　しかし、もっとも重要なのは、こうしたツールを導入することではないのかもしれない。同社では2013年から、インフラ部門の担当者を、各サービスの開発チームに紐付ける組織改変を行っている。石川氏がインフラチームから、アメーバ事業部に配属されたのも、こうした流れの一環だ。

　「以前は、インフラ担当で1部門、各サービスの開発チームがサービスに紐づく体制でしたが、今年からは私がそうであるように、インフラ担当者は各サービスの開発チーム側に所属しています。このため、サービスのプロデューサや開発チーム側の会議にも参加し、初期の段階から議論を行っています。当然、オフィスの座席もサービス開発チームの中。何か問題が起こればその場で議論できます」（石川氏）

　こうした、サービス単位での小さなチームを作ることで、インフラ担当者、開発担当者、UIの担当者の物理的距離を縮め、コミュニケーションの円滑化を推進している。

　「会議の場では、プロデューサもUI担当者も開発者も同席する。その場でおのおのの立場でこれから始めるサービスについての議論が可能になり、また、実装前の段階でさまざまなアイデアを共有でき、よりよい形でのサービスを検討できる場ができました」（石川氏）

　一方で、石川氏ら、元インフラ運用部門の担当者同士では、インフラ担当者としての横連携の会議体も継続している。

　「会議では、インフラ共通の課題の検討のほか、各開発チームの課題やチャレンジする内容を共有します。実際に効果のある取り組みは自身のチームに共有しています」（石川氏）

　従来の組織が、「インフラ」「開発」などの縦串だけだとすると、現在の体制では、「インフラと開発によるチーム」を縦軸に、「インフラ共通」「開発共通」という横軸によるメトリクスが出来上がっている体制だといえる。