みなさんこんにちは。
ユニファでサーバーサイドエンジニアをしております田渕です。
新型コロナウイルスによる突然の生活の激変が起こってから、早くも半年近くが過ぎようとしています。 （居住している国、地域などにより、体感している期間は多少異なると思いますが。。。） 弊社でもこれまでに何度か、新型コロナウイルスにまつわる投稿をこのブログの中でしてきています。 経験したことのない状況の中、色々と試行錯誤をしながら進めてきたわけですが、今回は主としてここまでの「システム運用」について振り返ってみたいと思います。
前提
これを読んでくださっている方はおおよそご存知かと思いますが、ユニファは保育園、幼稚園、こども園様向けのプロダクト/サービスを提供しています。 したがって弊社では、新型コロナウイルスにおける緊急事態宣言のもとにおいても、平時と変わらない(あるいはそれ以上の)レベルでの安定したシステム稼働が必要でした。
どんな状況だったのか
勤務体制
何度かこちらのブログでも紹介している通り、ユニファのエンジニアは元々リモートワークが可能な勤務形態でした。 これまではリモートワークと言えばエンジニアがメインでしたが、緊急事態宣言に伴い、全社的に可能な限りリモートワークを行う体制に移行していました。
エンジニアのリモートワーク状況については、下記の記事を参考にしてください。
システムの利用状況
以前、弊社エンジニアの島田が、緊急事態宣言下での保育施設利用状況について、本ブログにてまとめてくれたことがありました。
このブログの中でも書かれている通り、3月~5月は園児さんの欠席率が大きく上がり、保育園の稼働率も例年の同時期と比べると大きく下がっていました。
何が難しかったのか
ここまで聞くと、システム負荷が低いだけだし、そんなに問題はないのでは、……とお考えになるかと思います。 が、実は裏側では、日々バタバタしていました。
難しくしていた原因その1:いつもと違う利用のされ方
平常時と異なる状況なので、いつもとは少々異なる負荷の傾向が現れていました。 具体的な例では、先に紹介した保育施設の利用状況のデータをまとめたブログ中でもご紹介した「欠席コメント欄への記入率違い」などが挙げられます。
緊急事態宣言が発令された2020年4月7日以降で、明らかに利用の仕方が変わっていることが分かると思います。 この様な事例が、幾つか見受けられました。
システム保守をしているサーバーサイドエンジニアならば多くの方がシステムの利用状況、負荷状況を日常的に気にされていることと思います。 通常、システム利用の予測というのは、これまでの利用データ、負荷状況、利用者数の増加予測などを元として行っていきます。 しかしながら、新型コロナウイルスに対しての様々な新しい対応が日々、各所で行われる中では、これまでの利用データがあまり参考にならず、かつ今後の利用者数の予測を行うことは非常に難しいことでした。 基本的にシステムというのは、ある一定の想定条件下で正常に動くように各所のパラメータが調整されているので、その条件を外れれば正常に動かない箇所も出てきます。 事前に考えられる事態に対して対策はしていましたが、やはり事前には予測していなかった状況に直面しました。 それらのうちの幾つかの要素を原因としたトラブルに見舞われる中、地道にデータを分析し、暫定対応、恒久対応を行っていくことで事態の収束を行いました。
難しくしていた原因その2:全社的なリモートワーク
エンジニアのリモートワークはこれまでも行って来ていましたが、全社的に大多数の社員がリモートワークになるという状況は初めてのことでした。 どの会社でも同じだと思いますが、トラブルの発生の折には社内の関連部署への連絡が必須となります。 平時であれば誰かしら出社していたので、速報を口頭で伝えるということもしていたのですが、全員がリモートなのでSlackでの連絡が全てのきっかけになります。 元々エンジニアにリモート勤務が認められていた環境でしたので、Slackでの各所との話し合いは定着していたのですが、「口頭で速報を伝える」という手段を封じられるという状況はありませんでした。 もちろん、一番初めのきっかけ以降はリモートの会議体制に移行し、話し合いを行えますが、第一報はSlackです。 このことは、意外に緊急時に於いて、情報の速報性を妨げました。 というのも基本的にSlackは送ったからと言って必ずしもその場で読んでもらえるものでもないからです。
対策を考えてみる
緊急事態宣言が今後再び発令されるかは分かりませんが、少なくとも暫くの間はリモートでの勤務を継続することにはなるでしょう。 となれば、上記の困ったことを放っておく訳にはいきません。
いつもと違う利用状況に対して
必要となるのは、下記の要素だと考えています。
- 問題が発生した際の検知の早さ
- 影響の最小化に向けた取り組み
- 適切な暫定対応を行うための早期の決断
このうち、「問題が発生した際の検知の早さ」に関しては、ログやシステム監視の検知条件の見直しなどを実施し、平時と異なる利用があった場合に検知が可能となるように改善を行いました。
「影響の最小化に向けた取り組み」については今回利用した暫定対策の手順等をまとめ、次回の類似事象発生時には即座に適用できるようにしました。 また、問題の原因分析、システムの状況がより分かりやすくなるように、検知ツール類の設定の見直しも行っています。 が、これに関しては実際は発生した事象ごとに必要な情報も異なってくるため、実際のところは発生ベースでの対応となってしまいます。
残る「 適切な暫定対応を行うための早期の決断」については、次項で詳細を記載する体制の整備の中で承認ルートの見直しを行っています。
リモート主体勤務時のトラブル対応体制の整備
トラブルが発生した際、「どこのチャンネルで」「どうやって」一報を流すのかについて、改めて整備と認識合わせを行いました。 これまでも基本的に一報を流すことはSlack上で行ってきましたが、自身のチーム内や直接的な関係者しかいないチャンネルを利用していることもあるなど、その方法が統一されていませんでした。 今回のことを機に
- 一報を出す場所、メンション先、報告内容
- システム利用者への連絡方法
- トラブルによる緊急リリースが必要となった場合の承認ルート
の再整備を実施しています。
まとめ
今回は、今年2月以降で経験したことについて、備忘の意味も込めて記載してみました。 全く整備や準備が出来ていなかったという訳ではなかったのですが、非常時に於いてはほんの少し詰めの足りなかった部分が綻びとなり、顕著に形となって現れてくるものなのだなと感じています。 当たり前のことしか書かれていないのですが、当たり前のことが出来てないと非常時に困るんだ！ということを痛感した期間でもありました。 幸い、「もっとここが出来ていたらな。」という内容なので、今後も続くこの状況でもより安定してサービス提供を行えるように試行錯誤を繰り返して行こうと思っています。
自分たち自身も平常時と環境が異なる中、平常時以上のサービスレベルを保つと言うことはそれなりに苦労もありますが、一方で利用者の方から見て「動いていないと困るサービス」になれているのだ、と言うことが実感できた期間でもありました。 そのことは純粋に、有難いことだなと感じています。
ユニファでは現在も積極的に仲間を募集しています！ ご興味のある方は、お気軽にお声がけください。
