マネージドアプリケーションサポート・保守
すでに稼働しているソフトウェアを、御社のSLAとチケットキューの範囲内で動かし続けます。トリアージ、原因に対する修正、パッチリリース、依存関係とプラットフォームのアップグレード、セキュリティ対応、インシデント対応です。2次・3次対応を、開発も行うエンジニアが担当するため、繰り返し発生する障害は、再起動で済ませるのではなく修正されます。
なぜこれがパートナーの課題なのか
サポートは、マネージドサービスの中で、売るのは簡単でも人員を確保するのが難しい部分です。発生が不規則で、不慣れなコードを時間的なプレッシャーの中で読める人材が必要で、最も優秀なエンジニアを配置した途端、彼らはより収益性の高い仕事に回せなくなります。よくある対応は、何も修正せずにチケットを閉じるだけの、別の安価な階層を設けることですが、顧客は四半期のうちにそれに気づきます。
当社の答えは、サポート担当が技術者であることです。システムを説明するだけでなく、変更できます。繰り返し発生するインシデントが本当に止まる方法は、それしかありません。
当社が担うこと
トリアージと診断
1次対応で答えられないものを引き取り、再現し、「再現しない」として閉じるのではなく、実際に何が問題かを伝えます。
再発しない修正
不具合は原因から修正し、1件のチケットではなくバグの種類全体を対象にした回帰テストを書くため、同じインシデントが来四半期に戻ってくることはありません。
リリースとパッチ適用
パッチリリースを、御社のパイプラインと変更プロセスに沿って出荷し、依存関係、フレームワークのバージョン、プラットフォームのランタイムを最新に保ちます。アップグレードの危機に陥るまで放置することはありません。
セキュリティ対応
依存しているものに公開された脆弱性情報があれば、バックログの項目ではなく、無条件でアップグレードする理由になります。当社が追跡してパッチを適用し、どの程度の影響があったかをお伝えします。
監視とインシデント対応
すでにあるアラートを監視し、必要なアラートを追加し、インシデントを処理して、後から何が起きたか、どうすれば再発しないかを書面で報告します。
小さな変更
顧客を満足させ続けるのに必要でも、プロジェクトとして正当化されることのない小さな機能改善が、絶えず発生します。同じ体制の中で、同じ条件で対応します。
率直に評価した、御社のSLA
応答時間と解決時間の目標は公開していません。誰もシステムを見ていない段階で作った数字は、御社にとっても、御社の顧客にとっても無価値だからです。代わりに、御社がすでに負っているSLAを読み、そのうち当社が本当に担える部分とそのために必要な体制をお伝えし、それを書面で約束します。
時間外対応も同様です。案件で必要とされ、事前に合意した場合は、誰かを叩き起こして期待するのではなく、その時間帯のために採用またはアサインした人材が担当します。他の案件で、すでに欧州、オーストラリア、米国太平洋時間の勤務時間で稼働しているため、問題は可能かどうかではなく、どの時間帯が必要かです。
当社が構築していないシステムの引き受け
それが通常のケースです。これまでに9件の引き継ぎを行い、最も古いものは2008年に書かれています。
まず読み取り専用のレビュー
当社が何かの責任を負う前に、コード、インフラ、チケット履歴にアクセスし、変更ではなく確認をします。
リスクの書面
何が脆弱で、何がパッチ未適用で、何がドキュメント化されておらず、何が夜間の呼び出しにつながるかを、本番への影響が大きい順にまとめます。当社がその先に進むかどうかにかかわらず、御社に残ります。
カバー範囲の協議
御社が顧客に負っているSLAを読み、当社が担える部分、そのために必要な時間帯、費用を、どちらかが署名する前に率直にお伝えします。
引き継ぎ、そして本番稼働
現在知識を持っている担当者に付いて学ぶ期間を定め、その後、当社がキューを引き受けます。もう誰も知識を持っていない場合は、代わりにリスクレビューから始めます。
取り決め次第で、御社の名前で
サポートは、マネージドサービスの中で最も目に見える部分であるため、ホワイトラベルが最も重要になる部分でもあります。当社のエンジニアは、御社が発行するメールボックスとアカウントから作業し、御社のチケットシステムで回答し、御社がそのまま転送できるインシデントレポートを書きます。御社の顧客は、最初から最後まで御社とやり取りします。ホワイトラベル開発でその進め方を説明していますが、サポートにもまったく同じように当てはまります。
サポートの価格設定
1人あたり月額で、御社自身のコストが予測でき、それを基準に顧客向けのサポート契約の価格を設定できます。全員が当社のポータルで稼働時間を記録し、御社は月を通して稼働時間を確認でき、同じ数値から請求書を作成するため、双方が照合できる記録は1つです。
サポートが新規開発と並んでいる場合は、2つの契約ではなく1つのデリバリーポッドにするのが一般的です。一方が落ち着いている週が、もう一方の忙しい週を支えます。
サポートの取り決めに関するご質問
マネージドアプリケーションサポートには何が含まれますか？
すでに本番稼働しているソフトウェアを動かし続けるための作業です。キューに入ってくる依頼の仕分け、不具合の再現と修正、一次対応では答えられない技術的な質問への回答、パッチリリースの提供、依存パッケージとプラットフォームのバージョンを最新に保つこと、アラートの監視、障害発生時のインシデント対応が含まれます。これは二次・三次対応の業務であり、一次対応は御社の現在の体制のままです。
当社のSLAに沿って対応してもらえますか？
はい。応答時間や解決時間の目標値は公開していません。御社のシステムを知る前に決めた数字には意味がないためです。御社がすでにお客様に対して負っているSLAを読み込み、そのうち当社が担える部分と、そのために必要な対応体制を正直にお伝えした上で、書面でお約束します。
時間外対応やオンコール対応は可能ですか？
はい。時間外・オンコール対応は事前に取り決め、サポート条件に明記し、その時間帯に勤務する担当者が対応します。そのため夜間のインシデントは、たたき起こされた誰かではなく、シフト中の担当者に届きます。
他社が構築したシステムもサポートできますか？
むしろそれが通常のケースです。これまでに9件の引き継ぎがあり、最も古いものは2008年に書かれたシステムです。引き継いだシステムのサポートは、読み取り専用のレビューと、本番への影響順に並べたリスクの書面リストから始まります。そのため最初の数週間は、プレッシャーの中で推測するのではなく、実際に何に責任を負っているのかを理解することに充てます。
システムをサポートする担当者が、同じシステムの変更も行いますか？
はい。それが要点です。サポート担当のエンジニアは、チケットを閉じるだけの別階層ではなくエンジニア自身なので、繰り返し起きるインシデントも、毎週月曜に再起動するのではなく、原因から修正できます。開発とサポートの両方を当社に依頼いただいている場合、両者はコードレビューとアーキテクチャの意思決定を共有します。
サポートの料金体系はどうなっていますか？
1人あたり月額で、御社の費用が予測しやすく、御社のお客様へのサポート契約の価格もそれに基づいて設定できます。稼働時間は当社のポータルに記録され、月を通じて御社にも見え、同じ数値から請求書が作成されるため、双方にとって情報源はひとつです。
稼働を維持したいシステムはありますか。
システムの内容、御社のSLAの約束内容、現在サポートで困っている点をお知らせください。内容を確認し、当社が担える部分と、担えない部分をお伝えします。