エンジニアにとって運用保守が辛い理由

rio_dev

この記事は？


著者はエンジニアで働いてきて、設計、開発、運用保守、テストまで様々なフェーズでの経験があります。その中で運用保守を専門にするチームが存在していることはご存知でしょうか？うまく行っている運用チームでは自動化が進み、運用の最適化が進んでいますが、多くの作業を手作業で行い、日々がルーティンワークになってしまったチームだと色々な辛みが発生するようになります。エンジニア界隈でデファクトスタンダードであるテスト記述がないなど、コード品質に課題があり、しばしば古いバージョンを使っているためアプリケーションにもセキュリティの懸念が発生することがあります。

運用では何をやっているのか

どんどん新しい技術を身につけてそれを現場で活かしていくというよりは、今まで書いてきたコードの運用保守がメインになります。

新しい技術力を身につけてどんどんそれを活用していくというよりは、過去に導入された技術の運用保守がメインになります。なぜ過去に導入された技術が更新されていないのか？ですが、

①日々降ってくる業務に押されるがままに、時間が取れなかったこと。これには、自動化が進まず作業を手動で行ってきたと言う理由があります。
②技術/システムのメジャーなバージョンアップデートは高い技術力が必要であることから、なかなか作業が進んでこなかったこと。
③技術刷新の優先順位が低いまま、エンジニアが対応できなかったこと。エンジニアに危機意識があっても経営判断の優先順位が低かったこと。

などが考えられます。運用チームは日々どんな作業を行なっているのでしょうか？以下はどういう仕事を行っているかの例になります。

・クエリを用いてのデータの抽出
・Webページの一部分に対する更新
・サポートが切れた言語に追加でコードを記述
など、事業部から降ってくるタスクをこなしていく役割が多い。

エンジニア全体で自動化の感度が高く、自動化に対する工数を全社に主張できない限りこういった作業をエンジニアが手動で行うことになります。便利に対する概念が進みにくい環境であることから、使っている技術や普段の開発ツールが全体的に昔ながらになりがちな特徴もあると言えます。

監視チームとの違い

監視チームと運用チームが異なるのは、監視チームはインフラまたはアプリケーションが正常に動いているかを確かめる係であることです。こちらも未経験でインフラエンジニアになった場合アサインされることは多いですが、運用チームに立ち回りが近く、自動化を行なっていくことが効果的であるが、運用チームと同じような理由でそれが難しいと言う側面があります。

ガンガン進める役割ではない

新しい技術を積極的に学び、取り入れようとすることは大切なことですが、運用チームでアップデートされない既存コードの保守を行っていく場合ほとんど業務にて新しい技術概念を導入することはないと言えます。

また、一部の活気がある運用チームを除いて、そう言った最新技術に興味のあるエンジニアの在籍率も少ないと言えます。運用チームで大事なことは新規技術より既存技術をいかにメンテナンスするか？であるからです。

さらに、運用チームの特性上どうしても事業部から降りてきたタスクをこなす構造になりやすく、エンジニアがビジネスに提言する構造にはなりにくく、エンジニアの相対的に権力が低くなりやすい構造であると言えます。

こう言った環境で働いていると経験がその会社独自になりやすくなり、エンジニアが全社で積極的に活動をおこなったり、新しい技術を積極的に取り入れる組織では働きが難しくなってしまう懸念があります。

サイゼのPHP7は悪なのか？

最近Xで話題になったのはサイゼリアがPHP7のバージョンを使っているということです。

著者はセキュリティの専門家ではありませんが、ToCサービスの開発でセキュリティに関連する開発を行った経験もあります。PHP7系の公式なセキュリティサポートは2022年に切れているから、バックポートと言って新しいバージョンを当ててセキュリティホールを塞ぐようなことが必要です。

著者の経験から言うと、PHP7を使っていることは驚くべきことではなく、PHP5などメジャーバージョンが10年近く前に切れているシステムの運用保守を担当しているチームもありました。

そういったバージョンになると、もはや調べても情報が出てこないため古いバージョンの言語対応に長けたエンジニアの力が必要です。
著者は新規開発の経験がキャリアの中で長かったため、比較的最新のバージョンで開発できる新規のプロジェクトにアサインをしてもらっていました。

運用チームは変わっていけるのか？


著者は一時的に、多くの作業を手動で行っている運用チームに所属したこともあり、改善を行なっていくために以下のようなことを私自ら率先して行なうような働きをおこなってきたこともあります。

・テストコードが全くないプロジェクトにユニットテストを導入
・今まで手作業で行っていたjenkinsの複数フローを一括にまとめる
・CI/CDをプロジェクトに整備してPR単位でテストを行なう
・dependabotの概念をチームに説明し、脆弱性対応PRの自動作成化
・node.jsの新規プロジェクトにてメジャーバージョンごとにリリース
・クラウド化を進めていくために社内でAWSの勉強会を行なう

ただ、自分1人の力で限界を感じるところはあり、組織が歴を重ねれば重ねるほど、改善は難しくなっていくことや、品質やセキュリティに若干を懸念を感じたとしても、組織の中での優先順位が低い場合改善にリソースは当てられにくいのも事実。全体を変えるのは違った難しさがあるように見えます。

最後に (宣伝)

著者は、開発工程の中で運用保守が最も大切な工程の一つであると捉え以下の記事など、多くの運用保守に関する発信を行なってきました。

こういった基礎からしっかり学びたい初学者の方は、私が主催しているプログラミングスクールサブスクのご利用をご検討ください。

お仕事のご依頼は コンタクトフォームまで。



この記事が気に入ったらサポートをしてみませんか？