営業目線で監視運用の思い出を語る

これはMackerel Advent Calendar 2022の14日目の記事です

こんにちは、株式会社はてな Mackerelセールスチームでディレクターをしています。

  • 元々IT人生の最初の8年は開発エンジニアだったワタクシが、IT営業になって15年ほど経っています。現在、ご縁があってMackerelのセールスとして働いているので、つらつらと感じたことを書こうと思います。
    • 15年のセールス経験のうち、約10年はMSPベンダーでセールスとしての活動していた。先輩からのお誘いがあって、MSPベンダーに入社することとなったのが、運用だけで事業が成り立っていることすら知らなかった。DCやSIerが一部の事業として提供している思っていたのだ。
    • ちなみにMSPベンダーとは、ざっくりに言うと、お客様が構築したシステムに障害があった際に、障害対応をおこなったり、日々の運用作業などを代行する会社である。
    • 入社一番に感じたことは、障害が発生した時に真価を発揮する業務なので、基本的に業務が常にエマージェンシーだということだ。夜間に障害が発生すると、エスカーション先のお客様がまぁまぁ不機嫌だったり、あまり現場に携わっていない管理者などに電話が繋がってしまい、状況を説明しても理解してもらえず、復旧がすすまなかったりした。そんなときはMSPベンダー側のエンジニアがうまいことやってどうにか危機を脱するなんてことは少なくなかった。（たまに臨機応変にやりすぎて、後々恐ろしい状況に陥ったこともあったがそれはまた別の話）
    • MSPセールスを10年間ほどやってきた私だが、過去のエンジニア時代にはTivoliやJP1を使ったことはあったし、MSPセールス時代にはZabbixやNagiosを使ってMSP業務を提供していたので、現場経験も若干あるし、知識もゼロではないということで、CloudやSaaSがほぼなかった時代から現在にいたるまで、感じた変化を懐かし語りをしながら振り返ってみようと思う。

  • オンプレ環境は妙技の宝庫

    • MSP時代には困った時に泣きつくべきベテランエンジニアが頂点に座していた。本当に仙人の様な扱いだったような気がする。いつ会社にいるのかわからないなんてことはザラだったし、いつ電話しても繋がるのだ。まぁ仙人にしてはまぁまぁ地上に降りてくる。断続的に重大な障害が発生し、原因の特定ができない時、NWが逼迫されてパフォーマンスが落ちてしまっている時などに仙人たちの妙技が発揮される。ログをザザザザっと見て、ミドルウェアの設定を変更すると障害がおきなくなったり、NWの輻輳がサービスに耐えうる程度まで落ち着いたりするのだ。こう読み返すとあの外科医の様にも思えてきた。
    • お客様からの信頼も確かで「今回の調査に仙人を投入します」と言うと、お客様も「おお。それならば大丈夫そうですね。」と安心してくれたり、仙人を投入しても解決できない場合などは「それはもう仕方ないですね。調査を引き続き行いましょう」と、状況に理解を示してくれたりしていた。
    • 今考えると、（私が担当していたお客様のケースに限るかもしれないが、）お客様担当者さんも社内では緊急事態の時に活躍する役割なので、MSPベンダーと一致団結してとにかく業務を頑張っていこう。という雰囲気を出してくれていた様な気がする。
    • 思い出話が長くなったが、オンプレミスがメインだった時代は、リソースが足りなくなっても、すぐに追加できないので、他の用途で使っていたサーバーを無理やり繋ぎ込んでクラスタリング構成にしたり、メンテナス作業でも止めない様にするために、NWで無理やり別の経路を経由するなど、複雑な設定や構成になるはあたりまえだった。サーバーを育てていく感じに近かったと思う。僕の中ではスチームパンク的なイメージだ。そんな環境を監視するために、監視ツールはかなり作り込まれ、複数ツールとの連携や、グラフツールの混在などもデザインされていた。

  • Cloud台頭でMSP右往左往

    • 私の経験だと2012〜3年くらいから、AWSがお客様環境でも普通に使われる様になり、私たち（の会社）は戦々恐々していたのを覚えている。
    • MSP業務自体が必要なくなるのではないか？
      • 自動化によるサーバーのオートスケールは、障害検知時に新サーバとの自動入れ替えなどを可能になるのことで、人による障害対応は必要なくなるのではないか？ということである。一度Expo的なものに出展した時に、一人の来場者に「Cloudを使えば障害対応や運用業務は必要ない！」っと10分間言われ続けた。まぁ、結果としてそんな簡単に必要なくなるものではなかったが、さまざまなオーケストレーションツールなどの登場により、自動化の業務効率化はかなり進んでいると思う。だし、進めるべきだとだとも思う。
      • また、Cloudの登場により大きな変化があったのが、費用だった。様々な作業が効率化されたのだが、セールス目線で記述していこうと思う。
      • 私がMSPセールスだった時に、あるお客様のオンプレミス環境リプレースが、Cloud環境を用いて実施されることとなった。構築、および運用の提案を行うこととなり、それなりの規模の提案となったため、私自身も会社のエンジニアもかなり力を入れて提案を作った。数十ページに渡る提案書を提出したのだが、結果は失注となった。
      • 失注理由を探ってみたところ、私が提案していた提案金額の5分の1ぐらいだった。「構築も運用も」だ。その時の僕らは、「オンプレミスの手法のまま」で工数見積を作っていたのだ。middleWareや、サーバを一台づつ構築したり、接続試験や、UTもしっかりとテスト項目を洗い出して一台一台やるつもりだったのだ。
      • また、監視ツールもオンプレミスで使っていたものをそのまま使う前提としていたため、どうしても障害対応に手動対応が増えてしまい、コストがかかってしまう。適切なツールを使えば、Cloudの利便性を発揮し、大きな工数効率化ができていたのだと思う。他にもMSPサービスのメニュー化を試みるなど、いろいろな出来事があったが今日はこれぐらいで。

  • 監視運用は体制や用途に合わせて

    • ここまで書いて思ったことは、やはり監視運用は利用用途に合わせてデザインすることは基本的に変わっておらず、オブザーバビリティー、オーケストレーションなどを利用することで効率的、かつ効果的な運用を実現できるようになっているのだなと。一つのものを作り込むことは当然重要だが、新しいツールを使って便利を物事を進めることにビビってはいけない。手段に固執するとレガシーなものから離れられなくなり、大きな壁を越えられなくなってしまう。
    • また、以前は「開発エンジニアとインフラエンジニア」は、お互いに自分の業務範囲へ不可侵な雰囲気があったが、現在はかなり、業務的にも近くなってきている部分がある様に感じる。これもツールによって実現された効果の一つなのだろう。
    • Mackerelを使ってより、インフラ屋だけでない、さまざまな業種の人が利用しやすいサービス運用を実現するために、監視を育てていけるような提案、支援を今後もしていきたいと思います。「夜中はできるだけ寝たいですよね」を実現するためにも。