プログラマーにやさしいインフラを作るための4つのポイント

(Image from: http://blog.smartbear.com/apm/why-todays-apm-solutions-arent-optimized-for-devops/)

プログラマーにやさしいインフラを作るための4つのポイント

インフラに興味があるプログラマーが増えてきた

僕の勤務先に新しく入社されたプログラマーのなかで、 “インフラにも興味があるのでやってみたい” という意志を持っている方が増えております。やや意外に思う一方、僕もインフラは大好きな領域なのでとても嬉しく感じております。
このような意識の高い仲間に恵まれていることに感謝しつつ、その思いに答えられるような体制を維持していきたいと考えておりますので、この機会にまとめてみたいと思います。

クローズドなインフラ&運用チームに対する不信感

ランチなどで彼らに詳しい話を聞いてみると、 “前職ではあまり運用に深く関わらせてもらえず、インフラがブラックボックスしていた” という背景があったようでした。もちろん運用チーム側にも諸処の事情があったのでしょうが、そのようなイメージを抱かれていたということはきちんと信頼関係を構築できていなかったと考えられるでしょう。

“透明感のあるインフラと運用チーム” というのがキーとなる考え方だと思われますので、それを実現するために僕らがやっていることをいくつかピックアップします。

1. インフラ構成図を書いてすべてのエンジニアにシェアする

ブラックボックス化の一因として、インフラの全体的なアーキテクチャが見えていないというものがあると思います。僕が入社したときも簡単な概要図しか無かったため、色んな人にヒアリングして全体構成を把握していきました。

この課題に対するソリューションは簡単で、インフラ構成図を書いて社内でシェアすれば良いのです。下記は構成図の例です。(大人の事情により、ぼかしを入れてます)

Ad Platform

構成図を書くツールとしては Cacoo という SaaS 型のお絵描きツールがおすすめです。フリープランでも、 PNG などでエクスポートしたり、 URL 共有や共同編集などが出来ます。AWS コンポーネントのアイコン等もストアで無料購入できるので、 AWS インフラにも最適だと思います。

インフラ構成の変化に伴って、図を更新する作業が若干の手間ではありますが、そこは共同編集機能があるので協力してメンテすることで負担を分散することはできます。

qiita-infra

また、ペロリでは Qiita:Team という社内ドキュメント共有ツールを利用しているため、この構成図と文章による説明(利用技術等)とセットで説明のための記事を作成し、全員が閲覧できるようにしています。新しく入社された方に対する説明の資料として使うこともあります。

余談ですが、僕が書いた構成図が最近の社内勉強会で他のエンジニアに利用されていて、すこし嬉しかったです。 (^^

2. インフラの各種メトリクスを公開し、誰でも閲覧出きるようにする

ペロリではインフラの各種メトリクスのモニタリングに NewRelic, CloudWatch 等を使っています。
エンジニアはそれらを自由に見ることができる他、オフィスの壁にグラフや現時点のユーザ数などのデータをプロジェクターで投影しています。

トイレや休憩などで席を立つときに自然とそれが目に入るので、現在の負荷がどの程度かなどを常に肌で感じることが出来ます。
障害の時はこの画面が赤くなったり、グラフの山が急激に高くなったりするため、全員(非エンジニアも)が運用を意識することが出来ます。プロジェクタと電気代位のコストで実現出来ますし、全社集会のモニターとしても使えます。 (笑

そのほか、 Kibana のダッシュボードをエンジニアに公開しており、ログ情報をもとに自由にグラフを作れるような環境があったりします。

3. インフラの管理権限を可能な限り開発者に渡す

インフラの管理権限をどこまで開発チームに付与するかというのは大変判断が難しい課題の一つでしょう。

賛否両論はあると思いますが、ペロリでは多くの権限を開発者にお渡ししています。 AWS リソースの閲覧権限、サーバインスタンスや DB の作成等、日々の作業に必要なことは開発者自身で出きるようになっております。

とは言え、何のルールも無く権限を渡すのは丸投げしているだけですし、セキュリティ的にも好ましくないのでいくつかのローカルルールがあります。

  • ユーザごとにアカウントを発行し、異なる権限を持ったグループの何れかに属する
  • 権限はグループごとにホワイトリスト方式で管理し、権限が必要な場合は都度連絡してもらう (基本的には渋らないで付与する)
  • AWS CloudTrail を利用してすべての API 操作をロギングする
  • 個人情報を扱うなど、セキュリティ要件が厳しいプロジェクトはサーバにアクセス出来るユーザもガチガチに制御する
  • DNS 変更や DB の削除など、誤操作の影響が大きいオペレーションは禁止しておく
  • インフラの利用料金の推移は毎週チェックする

DNS や一部のサーバは Roadworker/Terraform 等を使って管理しているので、 GitHub の Pull Request によって変更を申請してもらうこともあります。

4. 障害対応も含め、プログラマーに “運用” もしてもらう

前述の通り、運用するために十分な権限をプログラマーにお渡ししておりますし、サーバ内の構成も Itamae (構成管理ツール) で定義して GitHub に上がっているので、プログラマー自身がサーバを構築したり設定変更出来るようになっていて、事実ペロリでも障害対応を含めてプログラマー自身が運用しております。アラートの通知先としても入れさせていただいております(もちろん僕も入ってます)。

なぜ、プログラマー”も”運用が出きると良いのかという点に関しては、ヌーラボの中村さんのスライドのドラクエの例が大変わかりやすかったので是非ご覧下さい!

前職だと開発と運用が明確に別の部署だったので、何か障害があったときにアプリケーション的な観点で対応してもらうのに割と苦労する部分があったのですが(社内調整的に)、ペロリですと Dev的 か Ops的 かの区別無く、運用課題に対して最適な解決を素早く行えています。

まとめ: Dev と Ops に線を引かないことが協力の第一歩

いくつかピックアップしてみましたが、テクニカルな施策だけでなくチーム間の協力・信頼も不可欠です。例えば (4.) などは、組織的に Dev と Ops が分かれていると中々難しい部分もあるかと思います。

しかし、逆に考えると組織的に Dev と Ops に線を引いたり(部署を分ける・肩書きを変える)せず、 “ユーザ体験を最大化する” という共通のミッションを設定することで協力し易い体制を作ることは可能だと思います。

ドリームチームへの第一歩として、 “これは僕がやるべき仕事だから~~” など、自分の仕事について Dev と Ops の区別をするのを辞めてみてはどうでしょうか。 😉

DevOps Engineer, 山中


反論も含め、ご意見・ご感想は大歓迎です。
ブログ執筆を続ける活力となりますので、よろしければ下記のフォームか Twitter などでコメントを下さい。 (^^

Related

Comments

No Comments Yet!

You can be first to comment this post!

Post Reply