見出し画像

ゆこゆこ SRE の 2022 年ふりかえり

最近、温泉ソムリエを取った @kumagaias です。
さて、2022 年の SRE の個人活動を月ごとにふりかえってみたいと思います。

1 月 インシデント報告の可視化と集約

背景

インシデント報告が各所 (メール・社内ツール・Teams) で行われており、かつ各担当者で閉じた連絡をしていたりして、何が起きているか分かりづらい状態でした。

アクション

インシデントレベルを 4 段階で策定し、これを物差しに皆で会話していくようにしました。

----- ↓ タスク化して対応 -----
レベル1: 軽微
レベル2: 機能の一部に障害

----- ↓ 緊急対応 (みんな集合!) -----
レベル3: 重要機能 (予約・顧客関連等) に障害
レベル4: サービス全体の停止

次に Teams にチャンネルを作り、報告をレベル別にそちらに集約することにしました。これにより「やばい」障害に皆がすぐ気づける状態になりました。

インシデント報告チャンネル


2 月 Datadog 導入

背景

監視ツールが Mackerel を基本に Sentry, CloudWatch と複数ありましたが、どこをどう見たら良いかわからず、監視設定は外注で、かつアラートが飛んできても誰もアクションしていない・・という状況でした。

アクション

上記の監視ツールを Datadog に統一し、ベンダーによる監視および保守を内製化しました。
年間 1,000 万円以上のコストカットになりました。

Datadog から Teams への通知も行い、かつ ALERT チャンネルは全員がウォッチするように周知を徹底したため、アラートが飛んできても放置の状況は無くなりました。

Datadog 通知チャンネル


3 月 Datadog 社内レクチャー & ダッシュボード作成

背景

Datadog を導入し、アプリケーションのパフォーマンス改善や効率的なエラー調査の基盤ができたものの、開発者にとってはまだまだ馴染みのないツールでした。

アクション

全社員向けに Datadog を LT する他、開発チームごとに 30 分 x 3 回のレクチャーを以下のテーマで実施しました。

フロントエンド: RUMダッシュボード
バックエンド: APMダッシュボード
ディレクター・QA : ダッシュボード

参加者からはその後、

・とりあえずどこ見たらいいかわかりやすい! (ダッシュボード)
・レスポンスが遅い時のボトルネックがわかりやすい! (APM)
・今までできていなかったフロントエンドのパフォーマンス計測ができた (RUM)


と嬉しい声が聞けました。

ダッシュボードに SLO も策定し、健康状態を一目でわかるようにしました。

Datadog SLO


4 月 Notion 導入

背景

ドキュメント周りでこんな声が聞かれました。

  • 仕様書の場所がわからないので、知ってそうな人に聞いて回る

  • プロダクトによってドキュメントがあったり無かったりする

  • どれが最新版かわからない

アクション

ドキュメント管理 PJ を立ち上げて Notion を導入しました。

「ゆこゆこドキュメント目録」を策定し、どのプロダクトでもこのドキュメントは作っていこう!とコンセンサスを取りました。

また Notion のデータベースを活用した「URL 一覧」「API 一覧」を作成し、そこにフロントエンドとバックエンドの仕様書を関連付けて体系化していきました。

まだ道半ばですが、他プロジェクトの人から見ても「ドキュメントを探しやすい」と声を頂けたのと、不足しているドキュメントが可視化できたのが成果です。

ゆこゆこドキュメント目録


5 月 QA チーム始動

背景

当時の専任 QA は 1 名でした。
私は 4 月から品質管理 G のリーダーとなり、新しい QA メンバーを 1 名迎えて 3 人となったので「チーム」としての動きを意識していきました。

アクション

リモートワーク下だったので会話を大事にしました。

  • 週 1 でメンバーとの 1 on 1 を開始 (オンボーディング期間は毎日)

  • チーム定例でファイブフィンガー & お困りごと・改善案を話す

  • チームビルディングのエクササイズを実施 (ドラッガー風エクササイズ)

実は各メンバーの担当範囲はそれぞれで、普段は実務を一緒にする機会はあまり無いのですが (しかも私のメインは SRE)、メンバー全員のカイゼン意識が高く、お互いの担当を超えて意見交換が活発です。

このチームの心理的安全性の土台があったおかげで、この後の極めて厳しいスケジュールの開発案件に対しても、 チームでフォローし合って乗り切ることができました。

なお 9 月から新メンバーを迎えて、現在は 4 人となりました。

下期キックオフではベストチーム賞を頂きました。ありがとうございました!


6 月 コーポレートサイト内製化

背景

コーポレートサイトは開発・保守を外注していましたが、改修が自由にできないとのことで、情報システム部で引き取り AWS で内製化することになりました。

アクション

当初は以下のシンプルな要件でしたが・・

  • WordPress をヘッドレスで使用

  • Next.js の SSG をデプロイする

リリース予定が決まった頃に以下の追加要件が出てきました😅

  • WordPress で投稿されたら即時反映したい

  • 特定のパスをリバースプロキシして欲しい

そこで AWS の方に技術相談に乗って頂き、

  • WordPress は lightsail でクイックに

  • Code Pipeline でビルド &  S3 にアップロード & キャッシュクリア

  • 即時反映は WordPress の post フックを使用し、投稿後にビルドを走らせる

  • CloudFront でリバースプロキシ

爆速で内製化 & 保守性と可用性が高いインフラが構築できました。
AWS 様、いつも相談にのって頂き本当にありがとうございます!

lighthouse での計測。表示も爆速です


7 月 全国旅行支援対応

背景

行政キャンペーンが自治体ごとに再開し、突発的なアクセスに備える必要がありました。

また、自社としても開発中の関連機能を「なるはや」でリリースし、機を逃したくないという意図もあり、メンバーに負荷が多い時期でもありました。

アクション

去年から、障害のふりかえり (ポストモーテム) を行っていた成果で、システムのボトルネックはわかっており、販促チームから SRE にキャンペーンの情報を必ず連携してもらい、事前のスペックアップをすることで障害を防ぐことができました。

また「なるはや」リリースでの QA メンバーへの負荷は、

  • 必要なテストを一緒に言語化してグループ化、工数見積、優先順位付け

  • 優先度が高いものは専任 QA が実施

  • 優先度が低いものは私も含め他メンバーが実施 

を行い、メンバーの土日出勤を防ぐことができました。

Notion にポストモーテムのテンプレを作成


8 月 Autify 導入

背景

QA の存在意義が高まるにつれ、テスト依頼が増え、QA 本来のテスト設計の時間が思うように取れない状況が増えました。

リリース前のリグレッションテスト等、定常なテストはなるべく自動化して、テスト設計に時間を使いたいというメンバーの声が高まっておりました。

アクション

Autify (テスト自動化ツール) を導入しました。
QA メンバーはエンジニア出身ではないため、ノーコードのツールを選びました。

Autify のオンボーディング支援 (3 ヶ月) も頂き、自動化のコツを学びながら少しずつテスト自動化率を上げております。
(2023 年 3 月中までに全テストの 30% 自動化を目標)

Autify
ビジュアルリグレッションテストが良いです


9 月 PostgreSQL 深夜メンテナンス自動化

背景

PostgreSQL では XID 周回問題 (age) があり、通常であれば autovacuum で age は自動で下がり問題無いのですが、自社では特定のテーブルで autovacuum が行われると、何故か DB 全体が停止してしまう、という歴史的背景がありました。

これを防ぐために毎月 1 回、サイト全体をメンテナンスのため約 5 時間停止し、深夜に人手で VACUUM FULL をしてメンテナンスを行うというトイルが存在しておりました。
SRE として何とか改善したいと思っておりました。

アクション

autovacuum のチューニングを行いましたが効果なく、3rd party 製の pg_repack (VACUUM FULL 相当をオンラインで実施可能) の検証に切り替えました。

残念ながら pg_repack のみでは age は下がりませんでしたが、デフラグの効果は期待通りに得られたため、pg_repack と VACUUM FREEZE と合わせ技でメンテナンスを自動化し、以下を実現できました。

  • 年間約 180 時間の深夜作業の削減

  • 年間約 60 時間のシステム停止時間の削減

お客様が 365 日いつでもサービスを利用できる状態になりました😁

メンテナンス開始時と完了時に Teams に通知


10 月 オウンドメディアの基盤刷新が完了

背景

ゆこゆこには以下の観光コンテンツのオウンドメディアがあり、フロントエンドチーム主体で Next.js x ISR 化を進めていました。

アクション

ほぼリードオンリーなフロントのホスティングだったため、AWS の Amplify Hosting を利用して基盤を構築しました。
サーバーやパイプライン構築も不要になり、保守性も高く、コストも抑えられ、表示速度も爆速になりました。

温泉旅行メディア「ゆこ旅」


11 月 セキュリティ強化

背景

2021 年末では log4j 対応など、SRE で目先のセキュリティ対応はこなしつつも、長期的なセキュリティ対策も行っていきたいと考えておりました。

アクション 

現在 Web アプリケーションの脆弱性診断を以下の方針で進めております。

  • 専門知識が必要な深い検査は、無理に内製化せずベンダーに発注

  • OWASP ZAP 等のツールで自動で定期的に行える基盤を内製で構築

また Cloud SIEM も導入し、リアルタイムでログ解析と検知を実施しております。

Cloud SIEM


12 月 開発チームビルディング

背景

2022 年は開発チームの人員の入れ替わりが激しい年でした・・😭

アクション

QA チームでのエクササイズが好評だったため、開発チームでもやってみませんか?と GM に相談したところ、快く OK! を頂きました。

以下、雰囲気の画像で恐縮ですがワーク内容になります。

day1

まずはお互いの相互理解を目的にドラッガー風エクササイズを実施しました。

ドラッガー風エクササイズ

day2

「トレードオフスライダー」をやってもらい、「品質」「期限」「スコープ」のうち、まず個人ではどれを大切にしているか可視化しました。
その後、チームで 1 つのトレードオフスライダーを作成しました。

トレードオフスライダー

次に「熱気球」で個人のチャレンジしたいこと・障害に感じていることを出してもらいました。

熱気球

day3

「熱気球」で出た意見をある程度グループ化したのち、意見が多かった順に優先順位をつけ、1 つずつ「あるべき姿」「解決案」「決定事項」を話し合って行きました。

「あるべき姿」「解決案」「決定事項」

1h x 3 セットの駆け足なワークでしたが、参加者からは

  • 実は同じことを考えているのがわかって良かった!

  • 色々な意見が可視化されて良かった!

  • これからどう実行するかが楽しみ!

と前向きな感想をもらえました😊

終わりに

ここまでお読み頂きありがとうございました!

ゆこゆこのおかげで育児と仕事を無理なく両立でき、自身のスキルアップもできた 1 年となりました。

ゆこゆこでは一緒に働いてくれる仲間を募集中です!
ぜひお気軽にご連絡頂ければ幸いです!
https://www.yukoyuko.co.jp/recruit/employeevoice/