インフラストラクチャー部の成田です。2015年10月現在、インフラストラクチャー部には私を含め7人のインフラエンジニアが所属しており、このメンバーでクックパッド本体サービスをはじめ様々な新規事業やいくつかの子会社のサーバを運用しています。私自身もエンジニアではありますが部のマネージャも兼ねているため、立場上、社外の方からインフラエンジニアのマネジメントについて質問されることがよくあります。今回は、私自身の考え方とクックパッド社における事例を紹介したいと思います。
「インフラエンジニア」とは
「インフラエンジニア」という言葉の定義はあいまいで、しばしば議論の的になります。傍目からは明らかにインフラエンジニアであるように見えるにも関わらず「私はインフラエンジニアでは無い」と主張する人たちもいます。このような状況になっているのは、サーバ運用に関する業務分掌が会社ごとに異なるからであると私は考えています。
今回はそこが本題ではないので、その議論は避け、クックパッドで「インフラエンジニア」と呼ばれているような人たちの事をインフラエンジニアと呼ぶことにします。サービス開発はせず、サーバ構築と運用を専門に行う人たちです。他にも「サーバエンジニア」「運用エンジニア」など様々な表現がありますが、ここではクックパッド社内の呼び方に合わせて「インフラエンジニア」と統一することにします。 なお弊社では現在物理サーバを持っておらず、AWS をはじめとする IaaS でサーバ運用を行っているため、弊社のインフラエンジニアは物理作業を行いません。
責任範囲
弊社では、インフラエンジニアは次の五つを責任範囲として持つ、と決めています。部内ではこれらをまとめて「五本柱」などと呼んだりします。
- パフォーマンス
- 可用性
- キャパシティ
- バックアップ
- セキュリティ
この五つの責任範囲は長年受け継いできたものですが、なかなか便利な分類なので今でも活用しています。 責任範囲を定義することは、業務分掌だけでなく、目標設定と評価に役立ちます。また、メンバーの仕事をこれらに分類してみると、どこに偏っているのか、何が足りないのかがわかりやすくなります。サーバの管理権限を持ち、なんでもできてしまう立場であるからこそ、自分たちにどういう責任があるのかをきちんと線引きしておくことは大切です。
以下、それぞれの責任範囲について説明します。
パフォーマンス
ユーザがサービスにアクセスした際に、適切な速度でサービスを利用できるようにする責任です。弊社のインフラエンジニアはサーバのパフォーマンスチューニングによってユーザ体験を改善する責任があるという意味です。 サービス開発自体はしませんが、サービスの変化によってレスポンス速度が悪化したときに、いち早くそれに気づき、改善まで責任を持って行います。改善においてはサービス開発エンジニアと連携をとりますが、インフラエンジニア自身がアプリケーションコードを書き換えてチューニングを行うこともよくあります。
余談ですが、弊部はサーバサイドのパフォーマンスチューニングを競技化した ISUCON にも積極的に参加しており、インフラエンジニア7人のうち4人が参加する3チームが ISUCON 5 予選を勝ち抜き、本選出場が決まっています。去年の ISUCON 4 では出題を担当しました。
可用性
サービスの稼働率を適切に保つ責任です。冗長化や監視技術などがこれに含まれます。可用性の追求には限りがなく、冗長化には冗長度に応じてコストがかかるので、どこまでやるのかを自分たちで決めなくてはなりません。従って、インフラエンジニアであっても事業ドメインの知識や収益構造を理解し、適切なサービスレベルを設計できる感覚が求められます。
キャパシティ
ユーザトラフィックを確実に処理できるキャパシティを確保する責任です。ピークトラフィックを予測し、適切な台数のサーバを用意するのはもちろんですが、台数を増やせばスケールするような設計をできる技術力が必要です。また、サーバ台数というのはコストに直結する問題なので、サーバのコストを最適化する責任があるという意味でもあります。従って、事業の収益構造を理解した上でサーバコストのかけ方を調整できるコスト感覚が求められます。
バックアップ
事業継続性を確保するために、事業にとって重要なデータをバックアップし、必要に応じてリストア可能な状態にしておく責任です。 バックアップ先ストレージとしては主に Amazon S3 や Glacier を活用していますが、最近では以下の記事のように、 AWS 以外のクラウドもバックアップに使い始めています。
複数のクラウドサービス間でオブジェクトストレージの中身を同期する - クックパッド開発者ブログ
セキュリティ
サービスのセキュリティを担保し、攻撃からサービスや情報を守る責任です。弊社のインフラエンジニアのうち1名はセキュリティエンジニアも兼ねていて、各サービスのセキュリティ診断を行ったり、サービス開発のスタッフにセキュアな設計のアドバイスを行ったりなど、セキュリティに関する様々な取り組みを担当しています。なお、サービスのセキュリティだけではなく社内の情報セキュリティについてもインフラストラクチャー部で担当しています。
インフラエンジニアとユーザファースト
クックパッドのスタッフが大切にしている行動規範として、「ユーザファースト」があります。 インフラエンジニアのユーザとは誰でしょうか。「ユーザ」という言葉を「インフラを提供する相手」として広く捉えると、次の2種類のユーザがいることが分かります。
- サービスのユーザ
- サービス開発をするエンジニア
インフラエンジニアはサーバを守るという役割上、どうしても保守的な考え方になりがちです。しかし、本当に守るべきなのはユーザ体験です。より良いユーザ体験を提供するために私達がするべきことは、決して権威的にならずに、開発エンジニアと密に連携して、サービスをスムーズに送り出すことです。
以下は2013年の資料ですが、開発と運用の連携について私が発表したものですので、詳しくはこちらをご覧いただければと思います。
Being healthy dev and ops in Cookpad // Speaker Deck
評価
他社のインフラ部門のマネージャから、インフラエンジニアの評価はどうしているのか、と聞かれることがあります。評価というのはつまり、成果の大きさなどを基準に、昇降給を決めることです。インフラエンジニアは事業に直接貢献するわけではない部門なので、評価が難しいという意見をよく聞きます。
私の考えでは、インフラエンジニアはウェブサービスに関わるエンジニアのなかでも、比較的評価がしやすい職種であると思っています。それは、成果を定量化しやすいからです。
先に述べたように、弊社のインフラエンジニアは「パフォーマンス」「キャパシティ」「可用性」「バックアップ」「セキュリティ」という五つの責任範囲を定めていて、メンバーが立てる目標は必ずこのうちのどれかに属しています。そして、それぞれの責任範囲には部として達成の定量的な達成指標を毎期掲げています。例えば、「パフォーマンス」であればサーバサイドのレスポンスタイム等、「可用性」であればサービスの稼働率や深刻な障害の数、といった指標を立てています。指標が定量的なので、メンバーがどれだけ部の責任範囲に貢献したかというのは明確にしやすいのです。
五つの責任範囲を守ることは確かに直接売上に貢献するわけではありませんが、ウェブサービスで事業を行っている以上、事業の基盤強化に貢献することに疑いはないでしょう。 インフラエンジニアの責任を明確にし、事業にどう貢献するのかを経営に理解してもらうのは、インフラ部門のマネージャとしての大切な役割です。
おわりに
今回は、弊社のインフラエンジニアの責任範囲と、その評価の事例を紹介しました。他社の事例もぜひ聞いてみたいので、各社のインフラマネージャの皆さんもぜひブログ記事に書いていただけると幸いです。
