# TAC生活を楽に ベンダー中立的な戦略で、チケット地獄を何とか耐えられるものに変える方法。 必ず最初にポータルチケットを提出してください。ログ、スクリーンショット、そして午前3時のパニック時の自撮り写真を添付できます。システムにチケットが登録されたらすぐに電話をかけ、優先度をエスカレーションしましょう。TACエージェントは、CFOのVPNが現在ダウンしていることを知らせる生の声を無視することはできません。後から少しずつ証拠を提供するのではなく、事前に証拠を提供してくれたことに感謝してくれるでしょう。 ほとんどのベンダーは、登録されている資格に基づいて自動的にトリアージを行います。CCNP、NSE 4、PCNSEなど、システムによってスクリプトリーダーを通過せずにTier 2に送られる資格に紐付けられたアカウントからケースを開くと、すぐにTier 2に送られてしまいます。バッジが手元にない場合は、チームメイトのバッジを借りるか、パートナー担当者にチケットを提出してもらいましょう。そうすることで、ベンダーはルールを逆手に取っていることになります。 メールのスレッドは温かいミルクのように古くなります。重大度「高」のチケットがコーヒーを買いに行く時間よりも長く放置されている場合は、すぐに電話してください。SLAはあなたの声が聞こえた瞬間から開始されます。TACのエンジニアは、あなたが保留音を嫌う以上に、侵害報告を嫌がります。 サポートの受信箱に大量のメールを送る前に、ベンダーのバグトラッカーまたはリリースノートRSSで5分ほど調べてください。「既知の問題、9.9.9で修正済み」というチケットを登録すると、まるでクレヨンでデバッグしているように見えますが、BUG-12345を引用すれば、きちんと準備をしたという印象を与え、多くの場合、すぐに回避策が見つかります。 ルーティングテーブルを削除した場合、TACはファントムルートを複製できません。パスワードとPSKをマスクすることはできますが、インターフェース、VRF、ポリシーはそのまま残しておきましょう。前進：TAC 用に一時的な読み取り専用管理者を作成し、コミット、エクスポートを行い、ケース終了後に削除します。 セキュリティポリシーによって設定のアップロードがブロックされている？ よし、ケース作成後すぐにリモートセッションを依頼しましょう。15分のライブビューイングは、「このコマンドを実行して出力を送信する」というやり取りを1週間も省き、お客様と同様に問題解決に注力していることを証明します。 トラフィックが原因不明で途切れた場合は、標準のパケットキャプチャとプラットフォームのフロートレース（`diag debug flow`、`monitor traffic`、`debug dataplane packet-diag`）の両方を添付してください。フィルター構文、タイムスタンプ、そして「14:07 に障害が発生した」という正確なマーカーを添付することで、TAC が状況を把握しきれない事態を避けられます。 どのベンダーも強力な「あらゆる情報を収集する」コマンド（`show tech-support`、`execute tac report` など）を持っています。これを一度実行し、gzip 圧縮してアップロードしてください。クラッシュログ、環境統計、プロセスダンプなど、いずれにしても面倒な情報を取得するので、事前に問い合わせをしておきましょう。 OSPFd が明らかに問題の原因である場合は、コントロールプレーン全体を一括デバッグするのは避けましょう。そのデーモンのみを 30 秒間詳細ログ出力に設定し、出力をキャプチャしてオフにします。ログが小さいほど、アナリストの満足度が向上し、根本原因の特定が早くなり、「監視中に再現できますか？」という問い合わせも減ります。 TAC が修正プログラムまたは回避策をプッシュした後は、チケットをオープンのままにして、少なくとも 24 時間は連絡可能な状態にしておきましょう。迅速なフィードバック ループにより、事後検証が始まる前に構成を微調整し、次の午前 2 時の停止時に利用できる評判ポイントを獲得できます。