運用保守のお仕事について

運用保守のお仕事について

組み込み業界に長年従事していた筆者が異業種の世界に飛び込んで半年経ちましたので、ポエム代わりに現在携わっている業務についてを書ける範囲で記事にしてみました
Clock Icon2023.08.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、高崎@アノテーション です。

はじめに

冒頭の「異業種」は少し大げさかもしれないですが、弊社にジョインして Web アプリケーションの保守業務に携わることになり半年が経過いたしました。

半年の振り返りとして現在の運用保守業務についてブログ化したいと思います。

運用保守業務について

運用保守業務には概ね、以下のようなものがあります。

  • 不具合調査・対応
  • エラーアラートの調査
  • 問い合わせ対応
  • 追加対応(画面リソースやマスターデータの追加・更新・削除)
  • ライブラリアップデート

今回は特に最後に記載している「ライブラリアップデート」についてを記載しようかと思います。

なお、実行環境は TypeScript を用いていることが多いですので TypeScript、Node.js 周辺を使用する前提で記載しております。

ライブラリアップデートについて

基本的な作業につきましては以下のブログの対応フローが非常に参考になりました。
npmパッケージのvulnerability対応フロー

バージョンアップの基本ポリシー

メジャーバージョンまで最新にする、というポリシーで進めているためncu -uを毎回使うようにしていますが、他にもプロジェクトによって様々なコマンドを更新時に入れていますので、package.json を

    :
    "scripts": {
        :
      "update:pkgs": "ncu -u && 他必要なコマンド諸々"
    :

のように実装しておいて、各プロジェクト統一でnpm run update:pkgsというコマンドを入力するようにしています。

アップデートあるある1.インストール出来ない

ライブラリは通常の制御にて使うものだけではなく、テストに必要なものもあり、そこそこな量のライブラリを導入します。

ncu により package.json の更新が出来たとして、その後に行うnpm install依存関係による影響により一回で成功しないことが多いです。

TypeScript 一つ取っても、最新は5.2.2(2023/08/30 現在)ですが、とあるライブラリは5.x.xで動作するが、他のとあるライブラリは4.x.xじゃないとダメ、といったことが往々にしてあります。

上記の場合、TypeScript を5.x.xのまま強行する場合は4.x.xを必要としていたライブラリの代替を探す必要がありますが見つからないことが多いため、TypeScript は4.x.xで進めることになります。

そこで、前回のバージョンに戻すのではなく限りなく4.x.xの最終バージョンにして、依存するライブラリが最新のままでよいかを調べながら対処します。

調査する際に重宝しているのが下記のコマンドです。

  • パッケージがリリースしたバージョン一覧を見たい
$ npm info パッケージ名 versions
  • パッケージの依存関係を見たい
適当なディレクトリに移動
$ npm install パッケージ名@バージョン
$ npm ls パッケージ名

特にバージョン一覧であるinfo 〜 versionsは頻繁に使いますが、出てきたバージョンを元にnpm install ライブラリ名@バージョン指定や、時には(あまり良くない手ですが)package.json を直に編集したりしてバージョンを指定し、npm installの実行してトライ・アンド・エラーで確認します。

この依存関係地獄については「yarnを使った方が良い」といった話もあったり、色々な情報もあるので勉強の日々です。

アップデートあるある2.ビルド出来ない

最新バージョンにしているとビルドが通らないこともままあります。

一番厄介なのがライブラリのインターフェースが変更された、いわゆる「破壊的変更」ですが、これは地道に粛々と変更していくしかありません。

しかしメジャーバージョンアップしておらず、インターフェースも変わっていないのにビルドが通らないことも良く起こります。

その場合はライブラリの GitHub の Issue 確認をして、同じような現象が出ていないかを確認します。

これが結構引っかかることがありまして、その場合は静かにその起票者に「いいね」の反応を付け、割と更新を頻繁に行っているライブラリの場合は対応を待つため一旦休ませるか、リリース日程で休ませられないと判断した場合は戻せる限界までバージョンを戻してまたトライ・アンド・エラーで繰り返し調査をします。

その他の業務について

その他の業務についても記載いたします。

不具合調査・対応とエラーアラートの調査の違い

不具合調査・対応は文字通り動かなくなった状態や明らかな動作不良状態における調査で、最も優先度が高い業務です。

一方、エラーアラートの調査は目に見えた動作不良は起こしていないものの、何らかの状態不良がログに残った場合に調査し修正が必要かどうかを都度判断します。

エラーアラートについては、今の我々の環境ですと Lambda や StepFunctions へログを出力させるようにしておいて、CloudWatch アラートチェックでアラート発生時に通知する形で監視しますが、仕込みのログを効率よく入れておく工夫が必要です。

問い合わせ対応

疑問点や、今後のご要望等のご意見を賜ることがあります。

できるだけ迅速にキャッチアップしつつ、回答についてもより最短距離で解消出来るようチーム内でも方向性をすり合わせ提出することにしています。

追加対応(画面リソースやマスターデータの追加・更新・削除)

主な内容としては、サービスを展開するエンドユーザ様へお伝えする情報(店舗の内容や外観写真、インフォーメーション等)の追加や変更があった場合に行う更新作業です。

これらは定型作業ですが、いかに正確に自動化するなどしてより効率よく業務を回すことが生命線だったりします。

おわりに

今回は我々が行っている業務について紹介いたしました。

参考になれば幸いですが、我々としてももっと良い方法がないか、常に情報をキャッチアップしてアップデートしていきたいと思います。

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。
「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。
現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。
少しでもご興味あれば、アノテーション株式会社WEBサイト をご覧ください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.