要約

  • AFRINICが公開しているService Level Commitmentは「Version 1 | November 2015」と記され、運用チーム宛ての全照会に2営業日以内で有効な応答を行うとする。その直下には12の受付キューがある。
  • 別のサポートメール一覧は16種類の専門窓口を示す。一方、Contact UsページはRegistry Queries、Technical Support、Media & Pressの3分類と、サービス種別を選ばない汎用フォームに絞っている。
  • この違いから、照会が紛失した、誤配された、期限を超えたとは言えない。確認できるのは、入口とSLC上のキュー、時計の開始事象、転送時の時刻継承を結ぶ公開表がないことだ。
  • 必要なのは窓口の削減ではない。用件、現行連絡先、責任キュー、受領時刻、再分類、代替手段、苦情とエスカレーションを一行で結ぶ、日付付きの対応表である。

まず専門用語を当てなければ時計が見えない

逆引きDNSの変更について問い合わせたい、とする。利用者に必要なのは、問題を説明し、受付番号を受け取り、次の手順を知ることだ。ところがAFRINICの公開ページを開くと、最初の判断が意外に難しい。

SLCではService supportが逆引きDNS、BPKI証明書、MyAFRINIC、Whoisを担当すると説明される。メール一覧にはAccount Info & Services、DNS and DNSSEC、DB-helpが別々にある。主要な連絡ページでは、Registry QueriesかTechnical Supportを選び、あるいはフォームに件名を書くことになる。

どの選択も誤りとは限らない。複数の入口を用意すること自体は、専門性と利用しやすさを両立させる普通の設計だ。ただし「2営業日以内」という数値を評価するには、どの入口で受付が成立したかについて双方が同じ記録を持つ必要がある。

AFRINICのService Level Commitmentは、運用チームに宛てられた全照会に2営業日以内で有効な応答を行うと述べる。付録は応答時間と解決時間を分ける。応答時間は、電話、メールその他の方法で提起された問題にどれだけ早く反応するか。解決時間は、問題が記録されてから完全に解決するまでだ。

ここは重要な長所である。複雑な資源申請やセキュリティ案件を2日で終わらせるとは約束していない。最初の応答は、受領、担当、追加資料、次の段階を明らかにできる。しかし、一般窓口から専門担当へ移る時間がどちらに入るかは、公開文書から読めない。

SLCが使う12の分類

2営業日の記述に続く表には、12の有効な行がある。How to Become a Member、Membership application Evaluation、Hostmaster、Billing、Service support、Service Infrastructure Maintenance、RPKI Support、DNS & DNSSEC support、Routing Registry、Website information、Complaint report、Complaint escalationである。

Hostmasterは追加資源の申請とIP資源管理の一般照会を扱う。Service supportは逆引きDNS、BPKI、MyAFRINIC、Whoisとオブジェクト操作の問題を含む。RPKI、DNS、IRRにはそれぞれの窓口がある。

この表を単なる古い住所録と片づけることはできない。SLCの応答条項を構成する一部として置かれ、各キューの対象が書かれているからだ。利用者は当然、自分の用件がこの分類のどこに入るかを基準に約束を理解する。

苦情の章では時間の流れがさらに明示される。電話またはメールで受けた苦情には、モーリシャスの祝日を除く2営業日以内に管理側が応答する。解決に納得できなければ、サービスチケット番号などを添えてエスカレーションでき、その苦情にも2営業日以内の応答が示される。

これは申立人の主張を認める期限ではない。解決完了の期限でもない。それでも、照会からチケット、苦情、エスカレーションへ続く筋道はある。この筋道を現在の受付ページに接続するものが必要になる。

専門メール一覧は16の分類を持つ

AFRINICのSupport Emails and Mailing Listsは別の思想で作られている。用件ごとに専門知識が必要なため異なるメールを設け、照会が見落とされないようにする、と説明する。技術組織として合理的だ。

一覧には16項目ある。Hostmaster/IP Resources、Billing、Account Info & Services、Routing Registry、DB-help、Prospective Members、Training、Outage、Fellowship、Fellowship Alumni、General、Escalation、RPKI、DNS and DNSSEC、Data Protection、IT security/Responsible disclosureだ。

SLCとの対応を推測することはできる。Account Info & ServicesはService supportに近い。OutageはService Infrastructure Maintenanceにつながるだろう。Prospective Membersは加入前の二つの段階をまとめているかもしれない。だが、推測できることと、公表されていることは違う。

SLCにあるComplaint reportという名称はメール一覧に見当たらず、Escalationだけが明記される。Website informationも同名では存在しない。一方、Training、Fellowship、Data Protection、責任ある脆弱性開示などはメール一覧だけで明確な分類になる。

この差が、異なるバックエンドを意味するわけではない。一つのアドレスが別名として働くことも、二つの表示名が同じキューに入ることもある。職員が時刻を維持したまま分類し直すことも可能だ。本稿は内部構成を調査していない。

問題は、それらの健全な可能性を利用者が確認できない点にある。名称の変更なのか、複数キューを束ねた入口なのか、サービス設計の世代差なのかを示す公開の対応関係がない。

主要ページは三つまで簡略化する

一般の利用者が先に見つけるContact Usは、さらに短い。案内される行き先は、Registry Queries、Technical Support、Media & Pressの三つである。加入、IPアドレス割り当て、BGPルーティングレジストリに関する質問にはフォームも勧める。

簡略化には明確な利点がある。新規申請者が「加入方法」と「申請審査」の境界を理解しているとは限らない。BGPに関する相談でも、IRR、Whois、RPKIのどれに分類されるか判断できない場合がある。広い入口は、利用者に組織内部の用語試験を課さない。

リンク先の汎用連絡フォームは、氏名、メールアドレス、件名、本文を求める。画面上には12のSLCキューや16の専門分類を選ぶ欄がない。自由記述の件名だけで正確に振り分けられるかもしれないし、画面に見えない情報が送られる可能性もある。

この調査ではフォームを送信せず、会員アカウントにも内部チケットにも触れていない。したがって実際の振り分け性能について主張はできない。言えるのは、送信者に見える範囲で、フォーム受付とSLCの時計を結ぶ説明がないことだけだ。

問題が現れるのは振り分けの後

適切な専門アドレスに直接届く案件では、三つの案内の違いは表面化しにくい。統治上の論点は転送にある。

例えば請求の質問がTechnical Supportに送られたとする。一般担当がすぐ受領し、Billingへ移す。一般担当は最初の受信から応答を測り、請求担当は引き受けた時点から処理を測るかもしれない。会員は公開された入口への送信から測る。三つとも記録として正確でありながら、同じ約束を測っていない。

苦情では連続性がもっと重要だ。SLCはエスカレーション時にチケット番号を求めるが、主要連絡ページにはComplaint reportという入口がない。汎用フォームで始まり、専門一覧のEscalationへ進んだとき、同じ番号と最初の時刻が自動的に継承されるかは説明されていない。

説明がないからといって、時計がリセットされるとは断定できない。正確な結論は、外からリセットの有無を検証できない、である。この空白は会員だけでなく、期限を守ったことを示したいAFRINICにも不利だ。

必要なのは受付対応表である

新しい大規模システムは要らない。短い表を一つ公開すればよい。

各行には、利用者が理解できる用件を書く。新規加入、資源追加、アカウント変更、請求、Whois、逆引きDNS、IRR、RPKI、障害、苦情、エスカレーション、データ保護、脆弱性開示などだ。次に現行の公開入口と、SLC上の責任キューを並べる。

時間に関する列は特に重要になる。正式受領はどの事象か。自動返信はそれを確認するか。どの営業日カレンダーを使うか。再分類と転送は最初の時刻を引き継ぐか。最初の応答目標はいくつか。解決状況は別にどう表すか。

代替手段も必要だ。専門メールが拒否された場合の等価な入口、フォーム停止時の送り先、通常照会から苦情へ移る条件、苦情からエスカレーションへ進む方法を記す。同じチケット番号が履歴をつなぐ設計なら、それも明示できる。

最後に版番号、発効日、責任部署、変更履歴を付ける。担当者個人の氏名は不要だ。アドレスを変更する自由も奪わない。旧入口から新入口への移行日と、移行中の時計の扱いが記録されればよい。

会員のメッセージ、IP資源、請求内容、セキュリティ対応手順を公開する必要はない。表が示すのは、公開された送信動作から、約束が適用される受付状態への接続だけである。

集計はプライバシーを守って出せる

対応表が固定されれば、月次の集計も意味を持つ。用件別の受付数、転送率、目標内の初回応答、未解決件数、経過日数の区分を示せる。苦情とエスカレーションも件数と時間分布にとどめられる。

少数の安全案件や個人情報案件は、まとめるか非表示にすべきだ。公開の目的は個別チケットを見ることではない。入口と測定対象が同じかを確認することである。

平均応答時間だけでは不十分だ。大量の早い回答が少数の古い案件を隠すことがある。転送時に新しい時計を作れば、達成率も実態より良く見える。最初の受領時刻を固定し、残件の年齢を併記することが、数字を解釈可能にする。

この証拠から言えないこと

調べたページには、紛失、誤配、期限超過の実例はない。試験メールは送っていない。内部のキュー、振り分け規則、担当者の手続も確認していない。三つの一般入口がすべての専門担当へ正しくつながっている可能性は十分にある。

2015年という版表示だけで、SLCが無効または放置されているとも言えない。ページは調査時に公開されていた。サーバーの更新日時も、内容の審査日ではなくサイト配備を示す場合がある。

また、2営業日は応答の目標であり、解決の期限ではない。本稿の提案はこの境界を曖昧にせず、むしろ受付時刻と解決状態を別々に記録する。

出典