はじめに
初めまして。りっちゃんです。
最近は休日の朝にランニングをするようにしました。一か月でフルマラソンと同じ42.195kmを走ることが目標なのですがなかなか達成できない今日この頃です。
小さいことの積み重ねが大切なのは知っているのですが難しいですね。
そんな私でもecbeingに入社して1年間続けてきたSRE活動があるので紹介したいと思います。
サービスを運用するうえで監視やパフォーマンスの可視化ができていないことが課題にあったため1年前からSRE活動を始めました。
何もない状態からSRE活動をどうやって始めて運用してきたかを簡単に紹介したいと思います。
SREとは
簡単に説明すると
SRE（Site Reliability Engineering： サイト信頼性エンジニアリング) とは、IT技術を使ってサイトの信頼性にコミットすることです。
SRE活動を始めたきっかけ
元々SREには興味があり前職でも少し活動していました。
ecbeingへ入社して『ReviCo』サービスの担当になり、サイト監視が整っていなかったのとNewRelicというObservability Platformの担当者になったこともあり一念発起して始めたのがきっかけです。
今思うと入社したばかりのタイミングでNewRelicに出会えたのは幸運でした。
NewRelicについて知りたい方はいかちゃんが書いた記事があります！
blog.ecbeing.tech
初めの一歩
委員会活動を始めるにあたって。
メンバー集め
半年くらいかけて担当しているサービスにNewRelicを利用した監視を導入しました。
所属する部署では複数のサービスを運用していますので、他のサービスにも監視導入を促進していたのですが、サービス固有の監視項目はサービスの開発チームの支援を得ないと達成が難しいものがあることがわかったためサービス担当者を巻き込む必要がありました。
少しずつですが、SREやNewRelicの知見をアウトプットしていたため、興味を持ってくれた方々を集めて委員会を作成することにしました。
一人で活動するのがちょっとだけ寂しくなっていたのも理由の一つです。
結成当初のメンバーは私を含め4名です。
メンバーそれぞれが、別々のサービスを担当しているため楽しいチームになりました。
現在は7名に増えてます。
ミッション決め
委員会になったからには目的をもって行動する必要が出てきました。
我々SRE委員会としてはサービスを持たないけど、全力でサービスを持つチームをサポートするという思いを込めてミッションを決めました。
価値のある顧客体験を提供し続けられるように 環境の変化に素早く対応できるチームづくりを支援する
ミッションを決めると組織っぽい感じが出るのでやる気も上がります。
活動内容
どんな活動をしてきたか。
NewRelicを使った監視
SREにとってObservability Platformは必要不可欠な存在。
使い慣れるまではとても大変でしたが、今では手放せない超便利ツールです。
いかちゃんの記事にも書いてありましたが、サイトの死活監視やDBの負荷、ユーザーの利用状況なども取得することができます。
さらに、アラート機能も備わっているため負荷が高くなったときすぐに知ることができます。
自前で作るのももちろん良いですがツールの保守運用に時間を使ってしまうのはもったいないので、SaaS型のツールを導入することで自分たちのSRE活動に専念することができます。
NewRelic以外にもツールはありますのでまずは導入してみてはいかがでしょうか。
標準監視項目を作成
NewRelicにも慣れてきて私が担当しているサービスに監視設定ができました。
ecbeingでは複数のサービスがありますが、どのサービスでも運用するうえで必要最低限の監視項目があります。
例えばDBやコンテナのCPU、メモリの利用率などです。
これらの監視をすぐに始められるように標準監視項目を定めました。
振り返りとチェックイン
結成してから半年くらい経ったころ、進捗が全くない期間が1～2か月ほどありました。
原因は委員会活動の優先度が低いのとやるべきことが具体的になっていなかったからかと思います。
委員会のメンバーには、本業であるサービスの付加価値の創造とビジネスの成長になるべく多くの時間を割いてもらいたいため、SREの活動にはやるべきことを絞って効果の高いものから着実に進めていく必要があります。
貴重な時間を使って活動しているので少しずつでも前進できる運用にしたいと考えて取り入れたのが、チェックインと振り返りです。
木曜日にチェックインを行い次の週の水曜日に振り返りを実施するサイクルを繰り返しています。
チェックインでは1週間以内でやるべきことと担当者を決めます。
ここで大切なのが、
- やることを絞り込む
- 優先度が一番高いものだけ実施するようにするぐらいの気持ち
- やることを具体的な行動まで落とし込む
- やることが曖昧なままだと結局何すればいいかわからなくて本末転倒
です。
さらに、私たちは属人化を発生させないようにモブワークを頻繁に実施するようにも心がけています。
振り返りでは結果と課題を共有します。
ここで大切なのが、
- 課題は正直に話す
- うまくいかないことを隠していると前進できません
- 終わらなかった原因を人のせいにしない
- 担当者を決めましたが、全員で解決していくようにしましょう
です。
次のサイクルで実施する方針まで決められると次のサイクルのチェックインがスムーズになります。
この仕組みを取り入れたことで少しずつですが常に前進することができ、目標達成することもできました。
スクラム開発のプランニングとレトロを真似たものです。
Azure Functionのログ監視
SRE委員会のメンバーが担当しているAzureを利用したサービスでは
- Azure Functionが正常終了したかどうかがわからない
- 正常終了してないAzure Functionあればアラートを上げたい
といったような課題があったためSRE委員会で対応することにしました。
課題を解決するために以下の方針で進めることにしました。
・Azure Function開始時と終了時に出力したログをNewRelicへ送信
・NewRelic側でログを集計し開始時と終了時のログ出力の回数に差があればアラートを上げる
いざ実施しようとしましたが、いきなりAzure Functionのログ出力ができないという壁にぶち当たりました。
ここで私たちがとった行動はチェックインと振り返りを利用して大きな壁を小さなタスクに区切って確実に前進することです。
1週間でやるべきこととして、タスクへの分解をメンバー全員で実施しました。
タスク分解ができたので、タスクに対して優先度と具体的な行動を決めればあとは行動あるのみです。
さいごに
私たちが実施してきたSRE活動を記載してきました。
NewRelicを使った監視のお話が多くなってしまいましたが、今後はSREとしてDevOpsの改善も実施していきます。
委員会活動として動いているためSRE活動の優先度が高くなることはありませんが、ecbeingにもSREを導入するために少しずつ確実に前進していきます！
こんなSRE委員会を盛り上げてくれる仲間をいつでも募集しています！
目指せ、委員会卒業！
最後まで読んでいただきありがとうございました。
少しでもSRE活動の役に立てられれば幸いです。
ecbeingではモダンを追い求めるエンジニアを募集しています！！
careers.ecbeing.tech
