オールアバウトでもSRE Gが発足しました。
9月まで技術基盤Gだった @takkyです。
昨今、Site Reliability Engineering (SRE) という考え方を採用する会社が主にWeb系の企業を中心に増えています。
SREを提唱・実現したのはGoogleと言われています*1
従来ではいわゆる運用チーム(インフラチーム)がインフラの管理を行っており、開発者と異なったスキルセットを持つ必要がありました。
このような組織では、「運用を安定させたいインフラチーム vs リリースを素早く行いたい開発チーム」のような対立も発生してしまいがちです。
GoogleでのSREが特徴的なことは運用チームにソフトウェアエンジニアを採用し、手作業で行っていた運用作業をシステム化していくという点にあります。
日本ではメルカリさんが採用したことで話題になり、徐々に採用する会社が増えてきています。
それに加えてオライリー・ジャパンからSite Reliability Engineeringの翻訳本が出たことも後押しになっているでしょう。
そんな流れもありオールアバウトでも10月からSREGが発足しました。
オールアバウトの今までのチーム構成
インフラチーム
もともと弊社ではインフラチームがあり、オンプレ環境の構築や運用を行っていました。
弊社のオンプレ環境に関しては以下の過去記事を参考にして下さい。
オンプレ環境では5年以上運営してきた事もあり、インフラ構成を全て理解することが難しい状態になっていました。
またChefを導入したのですが、導入しているサーバとしていないサーバが混在しており、運用が複雑化していました。
昨今のクラウドを上手く使って環境を構築していく流れもあり、オンプレ環境をクラウドへ移行することがインフラチームとして重要な仕事になりました。
しかし、現状のオンプレを保守しつつクラウドの機能を並列して検証していくということはなかなか難しいことになります。
そのため技術基盤Gが発足しました。
技術基盤G
2016年4月には技術基盤Gが発足しました。
技術基盤Gは開発エンジニアを中心に発足したグループで、主にCI/CD周りの改善やログ監視基盤の刷新、コンテナ化(GKE)や新技術の検証などを行っていました。
技術基盤Gが中心となって行った活動内容に関しては以下記事を参考にして下さい
特に、コンテナ環境(GKE)*2に関してはインフラチームと協力してクラウド移行やトラブル対応などを行ってきました。
しかし、クラスタの作成はインフラチーム、kubernetesのマニフェスト周りやDockerfile、CI/CDのセッティングは技術基盤G、最後の動作確認は開発チームと分担していることにより、オーバヘッドが生じてしまい効率の良い運用ができなくなってしまいました。
上記の問題を解決してオンプレからクラウドへ移行をスムーズに進めるためにも、この2017年10月からインフラチームと技術基盤Gが合流しSREグループとなりました。
オールアバウトにおけるSREチームの目的
よくSREチームのミッションとしてあげられるのは
- サイトの可用性の向上
- サイトパフォーマンスの向上
- トイル(運用業務)の削減
が言われています。
現状のオールアバウトのシステム運用状況を踏まえ弊社のSREGでは以下を行っていく予定です。
- クラウドに移行することで、可用性の向上を目指す
- インスタンス作成などの手作業での運用作業を減らす
- Infrastructure as Codeの導入
- ChefやTerraformなどでのインフラ構築自動化
- サーバの運用作業を減らす
- GKE(Google Container Engine)を採用し、変化に強く運用が楽な環境を目指す
- Google App Engine(GAE)などの採用も検討
- 定期的にある依頼作業の自動化 (いわゆるトイルの削減)
- ChatBotで開発者でも作業ができるようにする
- ツール化することで繰り返し行う運用の削減
- テスト環境(E2E, UnitTest)やCI/CD周りの整備
- メディアの安定性の効率向上の為
- 開発者が作成した機能を安全に素早く本番にリリースする
SRE Gのチームとしてはインフラのベテランから、開発周りが強い若手までバランス良くいます。
今後、更に自動化やInfraStructure as Codeの推進をしていきたいと考えているため、ソフトウェア開発をしつつインフラ運用面の効率を良くしていきたいというエンジニアを絶賛募集中です。
詳しくは以下のリンクを参照にして下さい。
実際に働いているSREに会いたいと要望があれば対応ができると思います。
よろしくお願いします。