Sheeprograming

先刻まで動いていた Google Spread Sheets を触るためのアプリが急に動かなくなった。作りは Java Quickstart  |  Sheets API  |  Google Developers を参考にしている。得られたスタックトレースは以下の通り。

com.google.api.client.auth.oauth2.TokenResponseException: 401 Unauthorized
	at com.google.api.client.auth.oauth2.TokenResponseException.from(TokenResponseException.java:105)
	at com.google.api.client.auth.oauth2.TokenRequest.executeUnparsed(TokenRequest.java:326)
	at com.google.api.client.auth.oauth2.TokenRequest.execute(TokenRequest.java:346)
	at com.google.api.client.auth.oauth2.Credential.executeRefreshToken(Credential.java:577)
	at com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:494)
	at com.google.api.client.auth.oauth2.Credential.intercept(Credential.java:217)
	at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:863)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:541)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:474)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:591)
	at com.hiyoko.discord.bot.MessageLogger.GoogleSpreadSheetLogger.initSheet(GoogleSpreadSheetLogger.java:77)

Quick Start の通りに作っているならば、普通に考えたら credentials.json がおかしいと考えるかもしれない。しかしcredentials.jsonがどう考えても正しい場合は tokens ディレクトリを疑う。このディレクトリはアプリによって生成されているはずだが、この中身が古かったり、壊れていたりすると認証が通らず 401 エラーが返ってくる。tokens ディレクトリをマルッと削除し再実行すると上手くいったりする。「おかしいな、昨日は動いていたのに」という時はこれの有効期限切れ等を疑うと良いかもしれない。

事故対応の秋である。そんな秋は来なくてもいいのだが事故対応の秋なのである。ここ最近ずっと事故対応を考えている（その1 その2）。

Google ではなんと Disaster Role Playing なる興味深いゲームをやっているらしい（ソース）。私は少し読めばわかる通り TRPG が趣味なのでこれは興奮した。しかし、正直これの GM をやれる人は私の所属組織ではごくごく少数だと思う。エッセンシャルな、重要な場面だけ抜き出して「一手目何を打つか」をディスカッションさせたりする方が現実的なコストかもしれない。

ないしは過去にあった事故データを関係なさそうな所まで詳細に記録しておけばそういうこともできるのかもしれない？それでも、決めていない所をプレイヤーが気にすることはあるだろうから結局 GM のアドリブは求められるだろうけれども。

もしかしたら、だが。お客様などといった外的な要因を気にしなければ TRPG よりは簡単かもしれない。想定していない行動への NPC のリアクションとか定めなくていいわけだし。

身内から「リンク先が PDF ファイルの場合にクリックしたらダウンロードされる場合とブラウザで開かれる場合があるんだけど、どういう違いで発生するの？」と問われた。これは a 要素に download 属性を指定することで容易に実現できる。リンク先が PDF でなくても使えるので html をダウンロードさせたりするのにも利用可能。

<p><a href="https://sheeprogramming.iku4.com/Entry/474/" download="lastArticle.html">前回の記事（ダウンロード用）</a></p>
<p><a href="https://sheeprogramming.iku4.com/Entry/474/">前回の記事</a></p>

以下が結果となる。

前に声を変えたいと言っていたがついに女性の声と勘違いしてもらえた。とはいえ、やっていたことは地道に前回書いた内容を念頭に置いた練習のみである。すなわち

1つ目の壁は男性の声にはエッジがあることだ。ぎざぎざ、ざらざらした声が男性の声の特徴である。これを取り除く尤も容易い方法は裏声を出すことだ。男性であっても裏声を出せばエッジの無い声を出すことができる。後は裏声を継続しつつ、裏声でも違和感のない声を出せれば女性の声になれるわけである。裏声を使わない、という流派もあるらしいが結局のところ裏声だろうが地声だろうが練習の際はこのエッジを除くことにかなり精力を注ぐらしい。

もう1つの壁は男性の声は抑揚が小さいことだ。女性の声は一般に抑揚が大きい。ましてや裏声のまま抑揚を大きくすることは至難の業だ。これは裏声でアプローチすれば、みたいな簡単な回答がないようだ。ただただ練習してみるしかない。

しかし、その場にいた人の半数は私の声から男性なのでは、と考えていたのでまだ半数しかごまかせていない。道のりは長く険しい。

本番環境におけるトラブル対応が難しい。実際にはトラブル対応そのものはちゃんと動くのだが、しばしば記録がちゃんと残されない。トラブル対応を担当した人はその記録を残すだけの余力がないのである。

Google - Site Reliability Engineering Chapter 14 - Managing Incidents において本番環境におけるトラブル対応について以下の4つの役割からなるチームで行うことを提案している。なるほど、手分けすれば記録もできそうだ。

Incident Command

The incident commander holds the high-level state about the incident. They structure the incident response task force, assigning responsibilities according to need and priority. De facto, the commander holds all positions that they have not delegated. If appropriate, they can remove roadblocks that prevent Ops from working most effectively.

Operational Work

The Ops lead works with the incident commander to respond to the incident by applying operational tools to the task at hand. The operations team should be the only group modifying the system during an incident.

Communication

This person is the public face of the incident response task force. Their duties most definitely include issuing periodic updates to the incident response team and stakeholders (usually via email), and may extend to tasks such as keeping the incident document accurate and up to date.

Planning

The planning role supports Ops by dealing with longer-term issues, such as filing bugs, ordering dinner, arranging handoffs, and tracking how the system has diverged from the norm so it can be reverted once the incident is resolved.

なんとなく日本語で楽に書くと以下の感じになるだろうか？

Incident Command (しれーかん)

トラブル全体を見渡し、関係者に役割を振り分けて担当する。トラブル対応がスムーズにいかないあらゆる理由をやっつける係。また、他の役割が担わない全てのタスクをやっつける

Operational Work (ぜんえい)

実際に本番環境に対して影響を与えるようなアクションを行ってトラブルを実際に解決する担当者

Communication（れんらくたんとー）

トラブル担当チームやステークホルダーと連絡をとり、情報発信を行う。また、関係する文書を最新の状態に保つ

Planning（ぷらんにゃー）

問題の記録や環境が予定とどう違う挙動をしたのかを追跡し、関係各所との調整を行って問題の後始末をする

現時点での私の感覚的には役割がちょっと細分化されすぎている印象を受けた。Incident Command が Communication と Planning を担えば私が今やっているお仕事の範囲であれば十分な気がしたのである。しかし、2つの役割には分けたい。対処を行いながら記録や関係各所への連絡までやる、というのは少々無茶が過ぎる。

しかし、トラブル対応を2人体制で行うための人員を捻出することが果たして可能なのか怪しいのではないか、という見解もある。人が単純に足りていないのもあるとは思うが、それに人を費やした際に得られる成果はせいぜい 1.5 人分ではないのか？という指摘を他の人から頂いたし、自分も少し感じている。人を分けることで得られるメリットは「ステークホルダーとの連絡がスムーズ」「トラブルの記録がきっちり取られやすい」があると考えている。これがのこり 0.5 人分ないしそれ以上のメリットを生み出せると断言できれば良いのだが。

2人体制でやる、となれば「姉妹制度」とか「ロッテ」とか呼びたい。なお、後者はドイツ語である。