システム運用保守の仕事はきつい？令和の運用保守とは、DWSのSREチームである

こんにちは〜！
コロナ渦で閉鎖されていたオフィスのカフェスペースが復活し、テンションが上がっておりますenaminです。
※DWSはフルリモートワークですが、オフィスも利用できます :）

そんな私は、復活したカフェスペースのコーヒーを飲みながら、お客様のシステム運用・保守を担当しています。

一方、「システム運用保守　仕事」まで検索に入れると予測変換で、

「きつい」
「しんどい」
「つまらない」
「夜勤」
「24時間」
「将来性」

などなど、不安そうな検索の跡が見受けられます。

そんな運用保守はもう古い！
今日はDWSで実践する「令和の運用保守・SRE」をご紹介します。

これまでの運用保守あるある

まずはこれまでのシステム運用保守の現場で主流だった体制について、おさらいしてみます。

マニュアルベースの繰り返し作業

エンジニアという肩書きがついていながら、

「本番環境のアップデートにあたっては、マニュアルに沿って、2人以上で、間違えないように最新の注意を払って作業する。」

といった、マニュアルありきの仕事が主になっている現場も少なくありません。

筆者は未経験からプログラミングスクールを経てDWSに入社したのですが、OBの先輩に「エンジニアとして生き残るなら、運用じゃなく開発エンジニアになった方がいい」と言われたことがあります。

先輩は「運用保守=ルーティンワーク」であり、ツールの発達やAIの台頭を踏まえると、開発エンジニアに比べ将来性が低いと判断されたのでしょう。

マニュアルで決められた通りに作業をすることが、運用保守の仕事の大部分を占めてしまっているというのは、今でもあるあるかもしれません。

24時間365日監視

いわゆる24/365と呼ばれる、24時間265日システムを監視する体制です。

休日・夜間を問わない不規則な勤務形態となってしまうため、筆者のような体力のない（運動不足なだけ）人にとっては、かなり大きな障壁となるでしょう。

そういった背景から離職率が高い組織になってしまい、結果残された人たちに負担が集中する悪循環にもなりえます。

怒られはするが褒められない

運用保守のゴールは、「システムを安定的に稼働させること」とされています。

正常に動いているのは当たり前、何か起こったら運用保守担当の責任を問われがちです。

安定的に稼働しているということは難しいことで、すごいことなのですが、目に見えない成果のためクライアントから褒められる機会は少ないんではないでしょうか。

いざ今からエンジニアを目指そうとする人たちが、こんな情報を目にしてしまうとひよってしまいますよね... ><

令和の運用保守ってこんなだ。

上にあげた「これまでの運用保守あるある」ですが、安心してください。
DWSでは「ないない」です。

トイル（繰り返し作業）を削減することがメイン業務

繰り返し実施する作業を、自動化していくことがメインの作業となります。

例えば最近だと、
脆弱性スキャン・通知をAWSのマネージドサービスに寄せて完全自動化や
セキュリティアップデート後のリグレッションテストを自動化
などなどに取り組んでおります。

トイルに取り組む度に新しい知見が増えるので、本来の「エンジニア」として力を発揮することが可能です。

9時に来て18時には帰る

全ての会社において、運用保守のお仕事が24/365体制である、ということではありません。

DWSのインシデント・お問い合わせ対応は9:00-18:00と決まっています。

必要に応じて「監視モニター設置→検知→通知→サーバー再起動」などのフローを自動化できるため、
人が介さずとも通知・復旧させる仕組みを導入することで、サービス停止のリスクを削減することも可能です。

お客様に+@の価値を提供できる

やはり一番嬉しいのは、お客様から感謝してもらえた時です。

課題に対して受け身に言われたことだけ応えるということではなく、
実現したいことから逆算して、最適な手段をご提案します。
DWSの行動規範でいうところの、More Trustにご対応するということですね。

そうした小さな改善が結果的に、システムの安定稼働に繋がり、
お客様にも喜んでいただける、自分たちも18時に帰れる（笑）という嬉しいループが生まれるのです。

エンジニアでありながらお客様と密にコミュニケーションをとっていけるのは、
DWSの運用チームだからこそだなあと、改めて感じています。

DWSの運用保守チームは「SRE」と呼ばれます

「令和の運用保守」などとかっこつけた表現をしてしまいましたが、SREと呼ばれるエンジニアリングの手法を取り入れているからこそ実現できるんです。

もう知ってるよという方は読み飛ばしてください。

SREとは

「Site Reliability Engineering（サイトリラビリティエンジニアリング）」の略称で、ソフトウェアエンジニアリングの手法および役割のことを指します。

SREは、システムやサービスの信頼性と可用性を向上させるためのアプローチです。
従来のアプローチでは、開発者は新しい機能の開発に集中し、運用や保守に関しては別途の運用チームが担当していましたが、
SREではエンジニアがシステムの信頼性に直接関与し、サービスの安定性を確保することを重視します。

SREの役割

1. サービスの可用性を高める

ダウンタイムや障害を最小限に抑えるために、モニタリング、アラート、エラー処理などの機能を組み込みます。

2. 自動化とスケーラビリティ

自動化によって人的ミスを減らし、スケーラブルなシステムを構築します。

3. 効率的なインフラストラクチャ管理

クラウドサービスやコンテナ化技術などの最新のツールやプラクティスを活用し、インフラ管理を効率化します。

4. インシデント対応と回復力（レジリエンス）

予期せぬ問題が発生した場合に素早く対応し、サービスの回復を迅速かつ効果的に行います。

DWSのSREチーム

さて、令和の運用保守ことSREのお仕事を紹介して来ました。

令和だなんだ書きましたが、DWSのSREチームは、まだまだ発展途上です。

かっこいいことを全てこなせているわけではなく、これから自動化したいトイルもたくさんあり、チームとしてのケイパビリティも向上させていっている途中です。

でも本当の意味で「Site Reliability Engineering」をチームで実現するため、OKRを設定・実行したり、より良いチームづくりのための読書会を行ったり、
泥臭く、一歩ずつ、チームで成長できるよう取り組んでいるつもりです。

SREチームに限らず、DWSのいいところはとにかく泥臭くがんばるところだと思っています。

もしこの記事を読んだ方がエンジニアなら、ぜひ他のメンバーの働き方や思いものぞいてみていってください。
ではまた！

enamin