この記事は SUPER STUDIO Advent Calendar 2023の19日目の記事です。
概要
どうも、弊社のアプリケーションの運用業務を担当しているエンジニア @urataku です。
ポケカ効率化用のスクリプトを書いて記事にしようとしていたのですが、
ポケカの大会に出たり、藍の円盤だったり、異次元フェスの鑑賞だったりとあまり時間がなかったのでポエムを書かせていただきます。
入社して1年半運用業務のチームしか経験したことがないため、現状の業務についてと日々気をつけていることを書いていきます。
そもそも運用業務って何？
弊社のサービス ecforce を利用されているショップ様からの問い合わせに対して技術的な問題を解決しております。
よくある内容は大まかに分けて下記になります。
- アプリケーション上で不具合と思われる事象の調査
- 管理画面上でできないデータ追加/修正
- 依頼されたショップのみで利用されるバッチの実装/改修
- etc...
自分たちが直接お客様とやり取りするのではなく、サクセスチーム、サポートチーム等のショップ様と密に連携する部署とやり取りをしてこれらの問い合わせを解決しております。
なんで入社時から運用業務をすることにしたか？
ecforceは1200のショップ様が利用されている大規模なECプラットフォームのため、
管理の都合上本番サーバーにログインできるエンジニアは、
運用業務を行っているアプリケーションエンジニア、インフラエンジニアのみとなっております。
エンジニアなんだから最初は開発を経験しろよと言われると思うのですが、
前職にて3人のエンジニアで全員何でも屋として働いていたので開発だけやるというのをあまり受け付けなかったのが一番の理由だと思いますww
またEC未経験ということもあり、手っ取り早くサービス全容を知ったほうが 給料を上げやすい 会社に貢献できるのではと思い、運用業務主体のチームに入りました。
運用業務を行ってきたメリット
実際に働いてみて正直大変なことは多いですが、下記のように色々とメリットは多かったと思います。
- ecforceの全容を把握が他チームより早い
- 本番環境の負荷を知ることができる
- トラブル対応、緊急対応に関わることが必然的に多くなるため、応用力がつく、優先度の判断の機会が多い
- わかりやすいログとログを置くべき箇所に気づく
- 開発職以外の方にシステムや、不具合の事象について説明する機会の増加
- 長年いるメンバーを開発チームに送ったらチームメンバー並みに活躍
普段から気をつけていること
主に普段から下記の点に気をつけながら仕事をしております。
言葉は相手に合わせること
正直、エンジニア、Pdmなどの開発職以外と働くことは珍しいです。
最初のうちはなれないこと多いと思いますが、なるべくエンジニアの言葉を使わないように気をつけましょう。
開発職以外の方ですともちろんGitHub等にも入れないため、コードやSQLで会話をしても相手には伝わりません。
なるべく、サービスで利用している言葉を利用します。
チケットに調査ログを書く時にエンジニアにも見てほしい文章があった場合は、エンジニア向けの文章も別枠で書きましょう。
例：
[NG]
CustomerAdminController def index()にて引数を与えないとcustomer_rank = 1のcustomerを取得しています。
https://github.com/[your_organization]/[your_repository]/master/controllers/customer_admin_controller.rb#L81-83
[OK]
顧客管理一覧画面にて、デフォルトで会員ランク：スタンダード会員(ID:1)の顧客が表示されています。
https://ecforce.example.com/admin/customer_admin/
---
# エンジニア向け補足
該当コードは下記になります。
https://github.com/[your_organization]/[your_repository]/master/controllers/customer_admin_controller.rb#L81-83
話が合わなければ早めに口頭確認
現在、どこでもslackなどでのチャットベースのやり取りが主だと思います。
チャットでのやり取りで2,3回話して認識合わなければそれ以上やり取りはせず、口頭で確認しましょう。
弊社ではバーチャルオフィスツールを利用しているため、
エンジニアもサポートもお互い認識が合わなければ即座に確認に行きます。
1つのサービスに数十人以上の方が関わっている以上、認識ズレは当たり前のように起こります。
なるべく期限内に回答を
ショップ様からの依頼を受け取っている都合上、大きな遅延は許されません。
(全部即日での対応ということではなく、相応の期日は各対応毎に頂いております)
もし期間内の解決が難しい場合でも、調査の一時的な回答や、目処の共有だけでも早めに共有します。
場合によっては、1ショップだけで起きている事象が、全ショップで起こっていた場合も多いので調査中にまずいと判断したら、すぐに共有しましょう。
すべてを1人でやらない
チケット管理で担当者は分けているものの1,2時間考えて解決の糸口が見つけられなかったら、他の方の目を借りましょう。
チームメンバー、開発担当者への壁打ち、サポート担当者への質問などは早めに進めていきます。
チーム内では毎日1時間難しいチケットを一緒に調査する壁打ち会を導入して、一人で調査を抱え込まないようにしています。
場合によっては、途中で担当者を変更することもありますので、
調査の一区切り毎にチケットへ調査ログを書くことにしましょう。
チームメンバーの導入が早い、サポート担当者が進捗を把握しやすい等のメリットがあります。
何度も似た調査を行わない
何度も似たような調査を行った場合は他の方に調査を譲るようにしましょう。
同じ方ばかりに知見が溜まってしまうのは、その方が休む、異動した際に対応できなくなる可能性が高いです。
なるべく対応したことがない方にメインの担当者として依頼して、壁打ちの壁役になりましょう。
チーム自体が強くなれば、あなたも次第に楽になります。
本番環境は怖いものと忘れない
あなたは神ではありません、ミスをすることもある人間です。
そうでなければ、私もごみ捨てをたまに忘れたり、電車に乗り過ごしたりすることはありません
同じBlu-ray Disc 37,000円を2つ買ってしまったのは洒落にならなかった、、、まぁ、なんとかなりました
業務上大きな権限を持つことにはなりますが、サービスはあなたのものではありませんので、
あなたの開発環境と同様に扱ってはいけません。
蝶よりも、花よりも丁重に扱いましょう。
特に本番環境で更新処理を行う場合などは特に注意しましょう。
注意する、努力するではだいたい解決しないので、仕組み化をしましょう。
仕組み化がすぐに難しい場合は普段から本番環境で作業をする際にダブルチェックを忘れずに進めましょう。
万が一それでもトラブルが発生したらすぐにアラートを上げましょう。
業務時間外で本番環境にログインするのは更に注意が必要です。
メンテナンスなどで数人いる状況なら良いですが、
そうでない場合は事故が起きたら、
エンジニア、サポート担当者、ショップ様の担当者等関わる方すべてに連絡がつながらず、
取り返しがつかない自体になります。
本番環境を直に触ることが避けられない業務ではありますので事故を防いでいければ幸いです。
まとめ
なんとなく、自分が日々思っている内容を元にポエムを書きました。
日々調査に追われることはありますが、
- エンジニア以外の方に伝える練習ができる
- 自身が開発しているサービスの全容を知る機会が増える
- 本番環境を実際に触るいい機会
であるため、あまり調査、トラブル対応をやられたことがない方はやってみても良いかなと個人的に思っております。
それを元にエンジニア組織を強くして自分の給料を上げていければ嬉しいです。