「スロットリング（throttling）」と聞いて胃が痛くなる人は、きっとメール（SMTP）システムを本格的に運用されているんだと思います。
知らない人は、知らないままでいた方が幸せかもしれません…
スロットル（throttle）は、動詞だと「抑圧する」・「首を絞める」という意味です。
名詞としては、自動車などのエンジンで燃料の流量を調整する「絞り弁」のこととなります。
概ね「流れを止める」というニュアンスのようです。
メールシステムにおいてそんなことをしたら、すなわち「メールが届かない」ということになります。
迷惑な話だと思われるでしょうが、実際に時々行われていますし、そこには一応ちゃんとした理由もあります。
決して、偶発的な事故や悪意のある攻撃ではありません。
ユーザーがデスクトップ上で行う操作の流れを、自動的に記録してくれるツールです。
実行コマンドは " psr.exe " 。
恥ずかしながら、つい最近までこの機能について全く知りませんでした。
マイクロソフトのサポートサイトは、できるかぎり原文、つまり英語版を確認することをお勧めします。
機械翻訳の日本語が明らかに不自然で分かりにくい場合はともかく、時々、自然な日本語で真逆の意味になっていることがありますから。
どうしてそんな罠を仕掛けるのでしょうか・・・
今日のテーマは「用語の統一性」です。
サポートという仕事柄、マイクロソフト社が WEB 上で公開している技術資料に日頃から目を通しています。
そこでは様々な専門用語が使われているのですが、同じものに違う名称が付いていたり、違うものが同じ名称で呼ばれていたりするので、首を傾げたくなることが時々あります。
私の勤めているサポートセンターには、システム利用者（エンドユーザー）からのお問い合わせが入ることは滅多にありません。
基本的に、システムの運用管理や構築作業を生業としているプロのエンジニアからのお問い合わせに対応しています。
しかし、開発企業がインターネット上で公開している情報をググった方が明らかに早いようなお問い合わせも、決して少なくありません。
インターネットへ接続していないクローズドな職場にいらっしゃるお客様なのかもしれませんが、そういう職場であればこそ、エンジニア向けの専門書が取り揃えてあるはずです。
Windows のヘルプメニューにも、TechNet と同じ内容が書いてあることがあります。
ところが、そういった情報源を全く活用せずにサポートセンターにお問い合わせいただくケースもあるので、ちょっと心配になってしまいます。
自力で調べても簡単には分からない事柄だった場合は調べた時間が無駄になってしまいますので、最初からサポートセンターへ問い合わせてしまえばよい、と考えるのは合理的かもしれません。
もちろんこちらも仕事ですから、聞かれたことには答えます。
ですが、それで解決できるのは「その時自分が直面した課題や疑問に思った事柄」だけです。
そんな場当たり的な対処を繰り返すだけでは、システムを構築・運用する上で本来知っておくべき体系的な知識は決して身につきません。
するとそのシステムは、たまたまその時の担当エンジニアが気にした問題だけが解決され、気にしなかった部分に意外な落とし穴があるリスクを抱えたまま運用されていく事になります。
そういう落とし穴がある（かもしれない）というリスクを自覚している方であれば、ググるなり専門書を読むなりして体系的な知識を身につけるよう努めるでしょうし、サポートセンターへ問い合わせる頻度も少なくなるでしょう。
（結果的に、サポートセンターへは「そうでない方」からのお問い合わせが集まっているような気がします。）
そのリスクを最終的に負っているのは、エンジニア当人ではなく、あくまでもシステム利用者だということを忘れてはいけません。
私自身はシステム運用・構築の現場で働いたことがありませんが、現場のレベルというのは、あくまでも現場のエンジニアの技術力に依存するのであって、決して現場が契約しているサポートセンターの技術力に依存しているわけではないと考えています。
もしサポートの契約など無い環境で同じ問題を解決しなくてはならなくなったら、誰だって自力で調べるはずです。
むしろその方がエンジニアとしては成長できると思います。
調べても分からないこと、調べる過程で派生した新たな疑問、調べた結果の妥当性確認といったことをサポートセンターへお問い合わせいただくことは有意義だと思いますが、そういうお問い合わせはあまり多くありません。
今回は、障害対応の初期段階のお話です。
コンピューターにおいて何らかの「障害」が発生したというお問い合わせの場合、まずは「それはどのような障害なのか」を明確にする作業から始めます。
作業内容を超ざっくり言うと、「こんな環境（条件）では同じ事が発生するだろうか？」といったようなことを、アレコレと試して試して試しまくります。
この作業は一般に「切り分け」と呼ばれます。
なぜそう呼ばれているのかははっきり分かりませんが、障害が「発生する環境（条件）」と「発生しない環境（条件）」を「切り分け」て、「病巣」を特定することだからだと思います。
回避策を検討するにしても原因を調査をするにしても、とにかくまず「切り分け」をしなくてはいけません。
相手が「どのような障害なのか」が分からなければ、手の出しようが無いからです。
たまに「原因の調査は後回しでいいから、過去に同じ事例があるかをまず教えてほしい。」といったご要望をいただく事もあります。
が、やはり「どのような障害なのか」が正確に分かっていなければ、過去の事例と照合することもままなりません。
さてこの「切り分け」ですが、実はこの段階では「技術力（知識）」はそれほど重要ではありません。
私の個人的な体感では、せいぜい二割程度です。
では残りの八割は何なのかと言うと、それは「思考力（知恵）」が五割と「経験」が三割です。
あくまでも譬え話ですが、「あるコンピューターで、あるアプリケーションが起動しない」という障害が起きたとします。
その時点でサポートセンターにお問い合わせいただいても、すぐにその障害を解決出来る見込みはほぼゼロです。
なぜなら、前述の通り「それはどのような障害なのか」がほとんど分かっていないからです。
こう言うと、「どのような障害なのかって？ それはもう分かっている。このアプリケーションが起動しないんだ。」と思われるかもしれません。
しかし、それはただ目の前で起きている「事象」を口にしているだけです。
決して、「それはどのような障害なのか」を説明していることにはならないのです。
障害対応をするうえでは、まず最初の段階でその違いを理解しておく事が非常に重要です。
では実際に、このような場合に行う「切り分け」の例を挙げてみます。
1. 他のアプリケーションは大丈夫なのか？
もし、そのコンピューター上で他のアプリケーションも起動しないのだとしたら、アプリケーションの問題ではなくコンピューターの問題だと言えます。
2. 他のユーザーは大丈夫なのか？
もし、そのコンピューターに他のユーザーでログオンしてそのアプリケーションを起動できるのだとしたら、ユーザーの権限の違いによる問題なのかもしれません。
3. そのアプリケーションは、これまではちゃんと起動出来ていたたのか？
もし、そのコンピューターでそのアプリケーションを起動できた事が一度も無いのであれば、そもそもインストールの仕方がおかしかった可能性も出てきます。
ざっと三つほど例を挙げてみましたが、こういった切り分けの結果が異なれば、まったく違う障害だということをお分かりいただけるでしょうか。
（これだけで十分ではありませんし、実際の障害ではより多くの視点から切り分けを行います。）
「目の前で起きている事」だけでなく、「他に起きている事」と「起きていない事」まで確認し、障害の「輪郭」を浮かび上がらせなくてな、「それはどのような障害なのか」を正確に把握出来ないのです。
しかし、実際の障害において行うべき具体的な切り分け作業が書いてある技術書は、なかなか無いと思います。
せいぜい代表的ないくつかの障害パターンに対して、上記の三つのような例が一般論として書いてあるぐらいではないでしょうか。
実際の障害は様々なので、どのような視点から「こんな環境（条件）では同じ事が発生するだろうか？」という切り分けをすべきかは、結局のところ臨機応変に自分の頭で考えるしかないと思います。
Windows はいくまでもなく米国製のソフトウェアですから、多くの技術文書はオリジナルが英語で記述され、それが世界各国の言語へ翻訳されています。
しかし、多くの技術文書は翻訳ソフトにより翻訳されているため、日本語としては不自然な記述であることも珍しく有りません。
そんな時は仕方が無いのでオリジナルの英語文書を頑張って読むのですが、むしろ積極的にオリジナルを読んだ方が良い理由が、実は他にもあります。
（正直言うと私は英語が大の苦手なのですが、仕事として Windows を扱っている以上、そうも言っていられません・・・）
それは、「文書の更新」です。
一度公開された技術文書も、必要に応じて随時更新されます。
しかし、日本語訳の更新がオリジナルに追いついておらず、大事な情報が加筆されていないケースが稀に有るのです。
例えば下記のページをご覧ください。
[オリジナル]
How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003
http://support.microsoft.com/kb/324270/en
[日本語訳]
Windows Server 2003 で DoS 攻撃に対して TCP/IP スタックを強化する方法
http://support.microsoft.com/kb/324270/ja
機械翻訳であるとの表記が無く、日本語としても自然なため、人力翻訳だと思われます。
手間をかけてくれるのは有り難いのですが、プロパティの項に記載された "リビジョン" を見ると、2013年12月2日現在、オリジナルが「14.0」で日本語訳が「2.0」です。
まるで追いついていない状態のまま３年近く放置されているわけですから、おそらく今後もこのままでしょう。
私も両者の内容を緻密にチェックしたわけではありませんが、大きな違いとしては「Note (日本語訳における " 注 " ) の数」が挙げられます。
オリジナルだと３つあるのに対し、日本語訳は２つだけです。
興味の有る方は、 " オリジナルに有って、日本語訳に無い Note " を見つけて読んでみてください。
けっこう大事な事が書いてありますよ。
Windows のサポートセンターに届くお問い合わせの内容は様々ですが、どんなお問い合わせでも受け付け時に必ず確認する事があります。
それは「回答期限」です。
実運用中のサーバーがダウンしたような障害であれば当然早急な対応が必要なのですが、すでにお客様側で復旧済みのケース（ OS を再起動したら元に戻った、等）の 場合だと微妙です。
そんな時によく言われるのが、「なるべく早く」という期限（？）です。
はっきり言って、この言葉にはほとんど何の意味もありません。
「なるべく早くと言っておいたのだから、なるべく早く対応してくれるに違いない。」
と思われているのかもしれませんが、そうなることは滅多に無いと言っていいでしょう。
なぜなら・・・・
具体的な期限が無いお客様は口を揃えて「なるべく早く」とおっしゃるので、残念ながら優先順位に差の付けようが無いのです。
リクエストされた期限内に必ず回答出来るとは限りませんが、たとえば
「エンドユーザーへの報告が○日だから、その前日までにサポートセンターからの回答が欲しい。」
といった形で回答期限を指定していただければ、こちらとしてもスケジュールを組み立てやすくなります。
そういった「根拠のある期限」が特に無い場合は、こちらからいったん一次回答の目処だけお伝えして仮の期限としておきます。
（その "仮の期限" に何か問題があれば、その理由をお伺いしたうえで再度調整します。）
サポートセンターも人員数には限りが有りますし、特定のお客様を専属で担当しているわけではありません。（そういう契約であれば別ですが。）
さまざまな案件を複数同時進行で担当していますので、優先順位の組み立ては重要です。
なので、サポートセンターからの回答が必要な日時が決まっている場合、理由も添えて伝えていただくことで「サポートセンターが期待通りに動いてくれる」確率が高くなります。
「なるはや」ではそれが出来ません。
なお、これは障害以外のケースでも同じです。
たとえば、「Windows Server 200X において、○○の設定の既定値は何か？ その設定が今がどうなっているかを、コマンドで確認する方法は有るか？」といったお問い合わせです。
このようなご質問の背景には、たいていサーバーのリプレース計画があり、各工程のスケジュールもすでに決まっています。
そのため、大抵は「○月○日までに回答をいただければ結構です。」と明確におっしゃっていただけるので助かります。
※ 二十項目以上の確認方法を、「明後日現地へ調査に行くから、明日中に教えて欲しい。」と言われた時にはさすがに参りましたが・・・
以上、サポートサービスを上手に使いこなすちょっとしたコツのお話でした。
私の勤務先には、Windows に関する問い合わせが毎日何十件も入ってくる。
クライアント OS についてエンドユーザーから問い合わせが入ることは滅多に無く、サーバー OS に関するサーバー管理者からの問い合わせが大部分を占めている。
一応、相手だってサーバー管理を生業としているプロのエンジニアなのだが、それにも関わらず、会話をしていて「正確な技術用語を使わない」人が少なくないことがどうも気になる。
ドメインコントローラーを「エーディーサーバー」と呼ぶぐらいならまあ理解出来るのだが、どこで覚えてきたのか見当もつかない造語を連発されると参ってしまう。
普段の自社内の会話ではそれで意味が通じているのかもしれないが、社外の人間と話す際にも通用すると思わないでほしい。（そもそも、社外の人間と話すときに社内用語を用いないことなど、エンジニア以前に社会人としての常識だと思うのだが。）
もしかしたら、社内用語を正式な技術用語だと思い込んでいるのかもしれないが、それはそれで勉強不足を露呈しているだけだ。
遊びではなく、仮にも仕事で Windows サーバーを管理しているのだから、関連書籍の一冊や二冊は読んでいて当たり前だし、職場にも常備されていなくてはおかしい。
書籍に記載されている技術用語を目にした事があれば、（普段はともかく、）サポートに問い合わせる際にはそちらの用語を使おうと考えるはず。
そういった書籍を一度も読んだ事が無いとなると、仕事に対する熱意まで疑ってしまう。
私自身はサーバー管理の現場（≒サーバールム？）で働いた事は無いので、サポートセンターに問い合わせをしてくる人達がどのような環境で働いているどのような人間なのかを、直接は知らない。
そんなことは向こうも同じなのだが、だからこそ、用語ぐらいは正式なものを使ってくれないと時間を無駄にするだけだということを少しは意識して欲しいと思う。