【保守実践編】適切に保守を使って最大限の価値を提供しよう

本記事ではネットワーク機器の保守について選び方や使い方を勉強します。特に顧客に対して提案したり、保守ベンダーに問い合わせする立場のエンジニアは知っておくと良い内容について記載します。

前回の基本編の記事を読んでからの方がより理解は深まります。

保守選定について

保守のレベル

機器を購入する場合、まずは機器の見積もりを取得します。大抵はその時一緒に保守の見積もりも依頼します。依頼すると言っても保守の中でいくつかレベルがあり選択する必要があります。厳密にはメーカや保守ベンダーによって内容は異なりますが一般的には以下のような種類（違い）があります。

センドバックとは交換作業なし、故障機の代わりに新機器が送られる保守形態です。故障機を先に送りその後新機器が送られるのが後出しセンドバック、故障と認められ次第すぐに新機器を送ってくれるのが先出しセンドバックです。

一方、保守ベンダー作業員が現地まで来て交換作業を全てやってくれる保守もあります。これをオンサイト保守と言います。新機器への設定流し込みや交換後の確認等ある程度スキルが必要ですし、場合によっては筐体自体が大きく自前での物理作業が難しい場合もあります。そういった場合に作業員に全てお任せできるオンサイト保守は非常に手厚いサポートと言えます。

また、オンサイトで作業可能な時間帯について平日の9～17時のみのパターンと24時間365日いつでも対応可能なパターンがあります。前者は一般的な会社の業務時間帯です。後者は本当にいつでも作業できるので、例えば夜間に急に故障した場合でも駆けつけてくれる、故障は平日日中帯に発生したが交換作業は深夜帯や休日に実施すると言ったことが可能です。

表の内容は下に行くほど手厚いサポートになりますがその分保守費用は上がります。SIerとしては過不足ない適切なレベルで顧客に提案する必要があり、顧客としてもなるべく無駄がなく費用を抑えたい意図があるので具体的な選択基準を見ていきましょう。

保守レベルの選択基準（センドバックかオンサイトか）

まず大きく分けるとセンドバックかオンサイトかという点があります。費用的にもここは大きな差があります。判断基準としては主に以下のような観点が挙げられるでしょう。

考え方としては顧客が自前で対応できるかどうか、復旧まで時間がかかっても問題ないかという点が重要になります。言ってしまえば自前でどうにかすれば良いレベルであればセンドバック保守で十分ということです。

ただし実際には、何となく雰囲気で重要そうだからオンサイト保守にしている場合がそこそこ見受けられます。保守内容や費用についてSIer⇔顧客間でしっかり合意出来ているのであれば良いですが、本当に必要なのか、必要であればその理由や判断基準まで含め理解しておくことが望ましいでしょう。例えば一口に「コアスイッチ」と言っても

• ①従業員数3000人の企業の本社コアスイッチ
• ②5人の事務所のコアスイッチ

ではレベルが全く異なります。①はL3スイッチ（冗長化構成）、②はL2スイッチ（シングル構成）になるでしょう。①は間違い無くオンサイト保守になりますが、②はどうしましょう？センドバックで十分なのか、オンサイトにした方が良いのか。答えはケースバイケースで顧客へヒアリングが必要です。

例えば暫くコアスイッチが使えなくても代替手段があり業務はできる、機器さえあれば現地担当者で交換できる、その分保守費用は抑えたい等々条件が合えばセンドバック保守でも可能です。一方、そういった材料が無ければ5人とは言え業務が止まってしまうのでオンサイト保守の方が安心です。

実際にはこういった判断の連続ですし、何が適切なのか？というのも難しい所です。例えばスキルの高い顧客担当者がセンドバック保守で運用していても、退職をきっかけに対応できなくなることもあり得ます。その場合は途中からオンサイト保守に変えると言ったケースもありますし、必要に応じて見直しも必要でしょう。

保守レベルの選択基準（オンサイト保守は平日9-17か24/365か）

オンサイト保守の中でも平日9-17時のみパターンと、24時間365日パターンで分かれます。後者は一般的な保守レベルとしては最大級に手厚いサポートです。もちろん重要な機器は24/365オンサイト保守となりやすいですが、これも本当に必要か、有事の際は想定通り発動できるか事前に確認する必要があります。

これは保守ベンダー側の体制の話です。24/365オンサイト保守とは「交換作業を24時間365日いつでも対応可」という意味です。ただし、交換するためには故障であると認定される必要があります。電源が落ちた等分かりやすい故障であれば良いですが、そうでない場合は機器のログを取得し保守ベンダーのエンジニアが解析します。

ここで重要なのは解析をするエンジニアが24/365とは限らないということです。例えば保守ベンダーエンジニアの出勤が9-18時であればその時間帯しか解析はできないですし、故障の判定および交換作業は明日以降になる可能性もあります。

ここの体制は保守ベンダーによって異なりますし、知った所でこちらでどうにかできる話では無いです。少なくとも窓口は24時間対応してくれますから可能な限り情報を渡し、後続対応に備える事になります。

因みにこれは保守ベンダーの窓口判断になりますが、ログの解析は出来ない場合でも状況を鑑み「予防交換」という形でオンサイト保守を発動してくれる場合もあります。あくまでもその場の状況や保守ベンダーの考え方にはよりますが最低でも以下のような要素は必要でしょう。

• 設定変更やトラフィックの急増等の外的要因がない
• 復旧しないと業務影響が非常に大きい
• 再起動やリストア（設定初期化、再投入）等可能な限り切り分けしたが復旧しない

また、24/365オンサイト保守は顧客側の事情も考慮する必要があります。

例えば保守交換作業時に顧客の立ち会いが必要な場所もあります。しかし夜間は顧客担当者が対応出来ず立ち会い不可といった場合ではどうでしょう？夜間にいざ交換が必要となっても保守ベンダーもビルに入館できないのでそもそも意味がありません。

夜間や休日であっても交換作業を実施できるというのが24/365オンサイト保守の最大のメリットなので顧客側の事情で有効に活用出来ないのであれば再考が必要でしょう。
※ここは念の為補足しますが、例えば深夜2時に故障してそこから顧客担当者が急に対応できないということは想像できるかと思います。一方平日日中帯に故障したが、交換時のユーザ影響を考慮して交換作業は22時開始で調整し、その作業は顧客担当者も立ち会うというパターンはあります。これであれば24/365オンサイト保守で契約するメリットはあります。

冗長化していたり、あまり使用頻度が高くない機器であれば必ずしも故障後すぐに交換という訳でもないですし、構成や顧客事情を鑑み適切な保守レベルを選択する必要があります。

保守開始時期

保守の開始日は一般的にはメーカ機器出荷日の翌月1日となるケースが多いです。例えば2020/9/15に出荷された場合、2020/10/1が保守開始、1年契約であれば2021/9/30までが保守期間となります。

一方顧客から見ると保守開始は遅い方が有利です。顧客からSIerへ発注し、SIerから販売店へ発注すれば近いうちにSIerへ機器は納品されます。プロジェクトとして考えればSIerへ機器納品後も設計やセッティングを進めている訳で、顧客の本番環境で稼働している訳ではありません。なので顧客からすると本番稼働前から保守費用が発生している状態なので、保守開始日を後ろ倒ししたいという要望が出ることもあります。

因みに保守開始日はメーカや保守ベンダーによっては調整可能です。これはモノによるとしか言いようが無いですがどうしても必要であれば交渉の余地はあるでしょう。

しかし、「保守は運用が始まってから必要」と思い込んでいると構築フェーズで弊害が出ることがあります。例えばセッティングの途中で設定方法が不明／挙動が怪しい、本番環境で切り替えをしたが不具合が発生した、といった場合にSIerのエンジニアだけで解決できれば良いですが、難しい場合は保守窓口に問い合わせを行います。しかし、保守開始日を変更しておりまだ開始していない場合はそもそも問い合わせが出来ません。

一応、単純な機器仕様の問い合わせレベルであれば担当営業経由で回答を得られることが多いですが、不具合やログの解析となると正式に保守契約が必要です。

このあたりは担当営業が影響や付き合いを考慮しフライングで対応してくれる・・・なんて事はあるかもしれませんが、あくまでも特例です。そのため保守開始日については以下のような配慮が必要です。

• リスクがあるなら後ろ倒しせず開始する
• どうしても後ろ倒しする場合、開始日前は保守サービスを受けられない事のリスクを説明し合意する

保守の使い方

問い合わせ時の注意事項

実際に保守窓口に問い合わせする際のポイントをまとめます。そもそも何故問い合わせをするのかというと「課題を早急に正確に解決するため」です。仕様や設定方法等の単純な質問であっても障害時の問い合わせでも共通するポイントはあります。問い合わせ窓口と言うと何でも知ってるプロ中のプロという印象があるかもしれませんが、相手もただの人間です。会ったことも無い人同士のコミュニケーションであることを前提に以下ポイントを参考にしてみて下さい。
※ここでは不具合発生時の問い合わせをメインに考えます。

①背景を説明する

問い合わせ時は、つい自分が知りたい用件だけを書きがちですが一旦落ちついて下さい。窓口の人はあなたのことも構成もどんな作業をやっているのかも全く知らない赤の他人です。

例えば、「スイッチの不具合があるので原因を調査したいです。」と伝えたとしても様々な事が考えられます。例えば以下のような内容です。

• 設定変更してから通信できなくなった
• OSのバージョンアップをしてから調子が悪くなった
• 何もしていないが通信が不安定になった

どのパターンかで調査方法や対処が変わってくるのは容易に想像が付きますよね。ある程度状況が分かれば窓口側も追加で踏み込んだ確認も出来ますが、そもそもの状況が伝わって無ければまずはそこから確認が必要になります。

つまりそれだけで最低でもメール1往復分は無駄になり解決までの期間が長くなります。見ず知らずの問い合わせ窓口担当者とのやり取りを楽しみたければ話は別ですが、当然ここの無駄なやり取りはなるべくスキップしたい所です。

早急に自分の知りたい情報を得るためには多少手間ですが、元々どういった状況なのか何も知らない相手が認識齟齬なく理解できるよう最初から説明しましょう。

②構成情報を説明する

どういった構成なのかを説明するかも非常に重要です。これも①同様「問い合わせ窓口は何も知らない」ためです。

例えば「スイッチの冗長化について教えて欲しい」とだけ言われても冗長化のやり方はいくつもある訳で、色々な想像が出来てしまいます。他の機器との接続もメーカが推奨するような接続かもしれませんし、かなり特殊な構成かもしれません。場合によっては正確な回答を得るのに構成情報が必要かもしれないので最初に情報を渡した方が問い合わせ窓口としても理解がスムーズに進みます。

ここで言う構成とは一番早いのは構成図です。型番情報や周辺機器との接続などが視覚的に把握でき、認識のすり合わせも確実に出来ます。

顧客側のポリシーによっては本番の構成図ファイルを外部に出せない場合もあるので、その際は簡易的な構成図を別で作成して渡す等工夫が必要ですが、いずれにしても文字で説明するだけでなく、別で渡せる情報があれば渡した方が話は早いです。

③自分で調べた情報や切り分け情報を説明する

例えば、スイッチの冗長化設定をしたが上手く行かず問い合わせたとしましょう。問い合わせ窓口としてはどういった接続をしているか、機器ステータスはどうなっているか等々確認します。

設定している人があまり分かって無ければそこの手間は止む無しですが、そうではなくある程度分かっているのであれば、確認した内容は最初に伝えた方が良いです。単純に一から確認となると無駄と言う点もありますが、どこまで調べたかを事前に整理することでより深い質問をすることが出来ます。例えば、

• XXXのメーカドキュメントを参照し、物理的にはこの通りに接続している
• YYYのコマンドでステータスを確認し想定通りの結果となっている
• しかし、試験をすると通信が切り替わらない

→ここまで整理できていれば質問は「推奨の物理構成で想定通りの機器ステータスなのに通信が切り替わらないのはなぜか？」というポイントに絞る事が出来ます。

どうでしょう？単純に「冗長化設定が上手く動きません」と問い合わせが来るよりも最初から具体的な確認ができそうですね。例えば、試験は具体的にどのようにやっているか？だとか、どこからどこへ通信しているのか？等質問が具体的である程それに対する確認や回答も具体的に返す事ができます。

また、調査状況を纏めてから問い合わせすると他にもメリットがあります。それは問い合わせ窓口担当者に自分のITリテラシーをある程度伝える事ができるという点です。

これは他人に何かを教えた経験がある人は何となく分かるかもしれませんが、教わる側がどの理解しているのかによって伝え方が変わってきます。例えば、

• 普段からPCを利用している人からExcelのvlookup関数の使い方を聞かれた
• PCに触ったことがない人からインターネットの開き方を聞かれた

上記2つのパターンではどうでしょう？恐らく教え方は変わってきますよね。前者の人は他の事は分かっていそうなので質問事項にストレートに答えれば大丈夫そうです。後者の人は恐らくインターネット以外の事も分かっていないのでそこからフォローする必要がありそうです。

これと同様に問い合わせ窓口の担当者から見ても、問い合わせした人がどの程度分かっているのかは不明なので基本的には丁寧に教えてくれる場合が多いです。一方、問い合わせのメールがかなり具体的で質問がピンポイントであれば、基本的な知識はありそうだと察するので初期から同じレベル感で無駄なくやり取りできる可能性もあります。

④質問事項を整理し、全て出す（小出しにしない）

これも無駄なやり取りを省き効率的に問い合わせするためのコツです。問い合わせのメールが長文になってくると結局何が聞きたかったんだっけ？の状態になりがちです。営業に対して問い合わせる時はそれで良かったかもしれません。営業はそもそも何が課題なのか、どう解決するかを一緒に考えるのが仕事であり、そこに価値があります。

一方問い合わせ窓口は具体的な質問に対し回答するのが仕事です。何が分からないのか分からない状態では窓口も答えようが無いので、何が聞きたいのか一問一答形式に纏めるのが理想です。

また、質問事項は小出しにせず最初に全て出してしまった方が良いです。これも単純に小出しだと時間がかかってしまうと言う点が挙げられます。また、窓口側の都合ですが、保守ベンダーによっては1つの質問に対し1ケースとしている所もあります。ケースとは1つの対応の単位です。要は問い合わせ毎に番号を付けて管理しやすくしているということです。

途中で追加質問をすると別ケース扱いとなり別メールに分割されることもあり、新規ケースの方は対応開始まで時間がかかる場合もあります。最初に質問事項を全て送っても最初からケースを分割される事もありますが、途中で挟むよりも時間は短くて済みますし、質問事項があるならば早めに連絡しましょう。

ただし例外もあります。例えば最初の質問の回答次第でその後の質問事項が大きく分岐するような場合です。こういった場合はまずは最初の質問を片付けてしまうのが先決でしょう。

問い合わせメール例

では具体的な問い合わせメールの例を見ていきましょう。保守ベンダーによっては問い合わせメールのフォーマットが決まっている場合や専用のWEB画面から問い合わせる場合があります。そういった場合は決められた通りに進めれば良いですが、ここでは特にそういったフォーマットはなく、フリースタイルで問い合わせる場合を想定しています。

#はコメントです。

————————————————————————-

件名：Catalystの通信遅延およびCPU高騰について
送信日時：2021/10/1 13:00

xxxサポートセンターご担当者様
お世話になっております。
yyyのzzzと申します。

CatalystのCPU高騰に伴う通信遅延と思われる事象が発生しており調査及び復旧に向けてご確認お願い出来ますでしょうか。既に数日間に渡り業務影響が出ており早急に解決したいと考えております。
#最初にざっくりの用件を一言で伝えておくと分かりやすい。単純な仕様確認なのか、障害なのかレベルでOK。もし急ぎであればその旨も最初に伝えましょう。

■機器情報
ホスト名：SV-SW01
型番：WS-C2960X-24TS-L
OSバージョン：15.2(7)E
シリアル番号：xxxxxxxxxxxxxx
#OSのバージョンによって動作は変わるのでバージョン情報は最初に提示しておく。
#シリアル番号は保守契約している筐体か確認する際に必要。保守ベンダーによっては契約番号が必要な場合も有り。

■構成
本社ではコアスイッチのL3スイッチは冗長化しておりクライアント及びサーバはコアスイッチ配下のL2スイッチに接続しています。コアスイッチ⇔L2スイッチ間はSTPで冗長化している構成となります。参考までに構成図を添付します。問い合わせ対象のスイッチに赤枠を付けております。

■発生事象及び調査状況
9/28 12時頃より本社及び他拠点ユーザより社内システムが異常に遅くなったと申告が複数挙がっております。
#特定の人やPCだけの事象ではない事を伝える。

この日前後で特に作業は行っておりません。また、社内システム以外のインターネットへのアクセスは以前と変わらず問題ありません。
#少なくとも作業起因ではない。また影響範囲を伝える事も重要で特定の宛先だけの事象発生であれば調査範囲を絞ることができる。

弊社にて切り分けした結果、社内システムを収容しているサーバスイッチ（赤枠の機器）に異常があると考えています。具体的には該当サーバスイッチにPC2台を直接接続しPC同士のファイル共有で通信速度を測定しましたが1Mbps程度しか出ておりません。
#該当機器が怪しいと考えている経緯、根拠を伝える。

なお、他のクライアント収容スイッチも同じ型番なので同様の方法で測定した所900Mbps出ており、明らかにサーバスイッチにて速度遅延が発生していると考えています。
#他の機器と同じ条件で比較し該当機器だけ正常で無いと考えている旨伝える。

サーバスイッチに関しては以下を確認しました。
・show processes cpu historyコマンドで確認した所、CPUが常時100%となっている
・show logコマンドには不審なログは見当たらない
・show interfaces countersコマンドで見た限り異常なカウントアップは無くループは無いように見える
　→何故100%になっているかが不明
・サーバスイッチの再起動を実施するも状況は変わらず
#こちらで確認できるポイントや他に思い付く切り分け結果を記載する。後々同じ事を依頼される可能性があるので確認したのであれば先に伝えた方が効率的。

■質問事項
(1)CPU100%の原因調査及び解決方法の提示をお願い出来ますでしょうか。
(2)他にハードウェアの異常や不審なログ等通信遅延に繋がる要素がないか念の為確認をお願い致します。
#質問は極力具体的に要点を絞った方が答えやすい。
# 量が多くなる場合は質問項目を分割をしなるべく一文章一質問で。

取り急ぎshow techコマンドのログを送付致します。他に必要なログ等あればご連絡下さい。
どうぞよろしくお願い致します。

————————————————————————-

上記は自前である程度ログを確認したり切り分けをできるスキルがあるケースでの問い合わせです。元々の課題は「社内システムの遅延」ですが、諸々調べた結果サーバスイッチのCPUが高騰していることが分かりました。そのため「サーバスイッチのCPU高騰」にフォーカスして問い合わせをしています。

当初の目的と問い合わせ内容がズレてると思う人がいるかもしれませんがいくつかポイントを解説します。

①根拠とセットなら推察はOK

このケースではサーバスイッチが速度遅延の原因だろうと推察し切り分けを進めました。ここで肝心なのはそう推察する根拠と一緒に提示している事です。ある程度の根拠があればそれは関係ありそうか、他のポイントを調べた方が良さそうか、問い合わせ窓口側もコメント出来ます。逆に「社内システムが遅いので調べてくれ」だけだと範囲が広すぎて調査に時間がかかってしまいます。いくら機器そのものには詳しいと言っても窓口側もログを見ただけですぐに原因を回答できる訳では無いのである程度当たりをつけるというのも重要になります。

また、最悪見当違いでも構いません。今回のケースで言うとCPU高騰が速度遅延の原因と考えていますが、本当は別の要因かもしれません。それはログの解析や今後の切り分けで判明するかもしれませんし、技術的な観点で誤りがあれば窓口から指摘があるはずですがそれでOKです。

ただしそういった建設的なやり取りをする上で、根拠は必要になります。事実は事実として正確に伝える、推察は根拠とセットで伝える、「混ぜるな危険」で意識しましょう。

②状況確認、切り分け情報はなるべく具体的・定量的に伝える

最初に、遅いのは社内システムのみでインターネットは遅くないと伝えました。もし全ての通信が遅いのであれば全通信が通過する機器を調べますが、社内システムのみなので調査対象を絞ることができました。

また、その後の切り分けでもサーバスイッチの速度が1Mbps(他のスイッチは900Mbps)、コマンドを打った際の結果等々具体的な内容を提示しています。

単純に速度が遅いと言っても体感的な所もあるので、元々遅かったのでは？だとかPC側の動作が重いのでは？等々本当の被疑箇所の特定に時間がかかります。しかし今回のように具体的・定量的な結果を確認することで少なくとも正常では無い事は分かりますし、さらに踏み込んだ調査に進みやすくなります。

③それでも他の可能性も捨てない

と、もっともらしい理屈で「速度遅延の原因＝サーバスイッチのCPU高騰」の路線で進んで来た訳ですが、直接的な原因でない可能性もあります。ここは現段階では判断出来ないのでその他の可能性の調査も並行して問い合わせています。この部分ですね。

>(2)他にハードウェアの異常や不審なログ等通信遅延に繋がる要素がないか念の為確認をお願い致します。

ここは窓口側がしっかりしていれば並行して調査してくれそうですが、基本的には怪しい箇所から順番に潰して行くことになるので、CPU問題が解決しても速度遅延が改善しなければ追って調査となるかもしれません。要は1つの観点だけに囚われるのでは無く、俯瞰して様々な可能性を考えましょうということです。

まとめ

今回は実践的な保守の選び方・使い方をまとめました。保守は上手く活用すれば悩む時間を短縮したり、難しい問題を解決できる武器になります。一方、効率的な利用方法を知らないと問い合わせのやり取りに時間がかかったり、故障時に迅速に交換出来なかったりと、かなり勿体ないです。保守・運用と一括にされがちですが実際には構築フェーズから使う事もありますし保守は蔑ろにはできません。営業、エンジニア、顧客全員が適切な保守に選定や使い方を知って初めて安定した情報システムの構築・運用ができるようになりますから、この記事の内容はよく理解しておきましょう。