set setting reset

脂肪と糖にはたらくやつ

富士そば 日暮里店と渋谷明治通り店

この記事は 富士そばアドベントカレンダー 2019 9日目の記事です。

adventar.org

がっつり遅刻です。申し訳ございません。

富士そば好き度で言えば先日、ラスベガスで開催された某カンファレンスに参加したのですが、
行く前から「帰ってきたら富士そばに行くんだ。。。」と考える程度の者です。

ラスベガスからはロサンゼルス経由で成田に帰国したのですが、成田から自宅への帰路としては京成スカイライナーで日暮里まで行き、そこからなんやかんやで自宅まで帰るわけです。
去年は巣鴨店に行きましたが、今年は別のお店にしようとGoogle Mapで検索すると、日暮里にあるわけですね。富士そば
まぁありそうな雰囲気です。

fujisoba-nippori - Google 検索

いかにもありそうな雰囲気だなぁと思いつつも、去年もどうせ調べた自分としては、それを見逃すはずはないなぁとか考えていたら割と最近開店したようでした。
ですよねー。

【開店】名代 富士そば 日暮里店

というわけで行ってまいりました。日暮里店。

f:id:rriifftt:20191207212157j:plain
富士そば 日暮里店 外観

看板が新しく、いかにもニューウェーブ富士そばという雰囲気。 駅近で使い勝手がよさそうです。

写真にもある通り、 肉骨茶そば なるメニューが見えます。なんだそれは。気になる。
でもあれですよ。合衆国からの帰国一発目の食事で 肉骨茶そば ほどの攻勢に出れる人間なんていませんよ絶対、きっと、たぶん。

そして完全に日和ったぼくはいつも通り紅生姜そばを注文したのでした。

f:id:rriifftt:20191207212823j:plain
紅生姜天そば

ところで紅生姜天そばっていつ頃からできたメニューなんでしょうね。
10年前くらいに富士そば1号店でカレーうどん3食していた頃にはなかったと記憶しています。
いや、あったかな。。なかったと思う。。

新しめの富士そばらしいカエシで黒すぎない感じのおつゆで、これはこれでアレです。
紅生姜天は鉄板なので、特に言うこともないです。 が、あえて言うなら 最 高 です。
ごちそうさまでした。


とはいえ、なんだかもうやっぱり気になって気になって納期のせまるお仕事が手につかず、困りました。
そう、 肉骨茶そば

というわけで翌々日に我がホームであるところの渋谷明治通り店に突撃です。

f:id:rriifftt:20191209123230j:plain

よかった。新進気鋭の日暮里店が編み出した独自メニューじゃなかった。
逆に言えば新進気鋭感があるこちらのメニューを複数店舗で販売する富士そばは相変わらずなんというかちょっとキてますね。
そして迷わず注文しました。

f:id:rriifftt:20191209123618j:plain
肉骨茶そば 引き
f:id:rriifftt:20191209123626j:plain
肉骨茶そば アップ

食べてみると、揚げにんにくが乗った塩豚骨?な感じでして、なんとも言えないデジャブに襲われます。
なんだっけこれ。。食べたことある。。でも麺は富士そばだ。。なんだこれ。。よくわかんない。。という感じでした。
おいしいかおいしくないかは自分にとって重要ではありませんが、不思議なインパクトがあるメニューとなっておりました。
たぶんもう食べないけど。

というわけでごちそうさまでした。

SSM Session Manager のポートフォワードを使って EC2 に RDP する

はじめに

SSM Session Manager でポートフォワードができるようになったそうなので、表題のことを試してみます。

環境

ローカルマシン

Windows 10 です。

> Get-WmiObject Win32_OperatingSystem


SystemDirectory : C:\WINDOWS\system32
Organization    :
BuildNumber     : 18362
RegisteredUser  : Windows ユーザー
SerialNumber    : 00330-51554-55623-AAOEM
Version         : 10.0.18362
> $PSVersionTable.PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      18362  145

> (Get-Module AWSPowerShell).Version
Major  Minor  Build  Revision
-----  -----  -----  --------
3      3      509    0

AWS Tools for PowerShell の Credential 設定

> Set-AWSCredential -AccessKey ************ -SecretKey ************* -StoreAs default
> Initialize-AWSDefaultConfiguration -ProfileName default -Region ap-northeast-1 

後述しますが、設定したはいいものの AWS Tools for PowerShell は使いませんでした。

接続先のEC2

  • Windows Server 2016
  • SSM Agent 2.3.714.0
    • 2.3.672.0 以降であることが必須要件
      • バージョンが低い場合は Run Command から AWS-UpdateSSMAgent が便利
# AWS-UpdateSSMAgent 実行時のログ

Updating amazon-ssm-agent from 2.3.539.0 to latest
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/ssm-agent-manifest.json
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/amazon-ssm-agent-updater/2.3.714.0/amazon-ssm-agent-updater-windows-amd64.zip
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/amazon-ssm-agent/2.3.539.0/amazon-ssm-agent-windows-amd64.zip
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/amazon-ssm-agent/2.3.714.0/amazon-ssm-agent-windows-amd64.zip
Initiating amazon-ssm-agent update to 2.3.714.0
amazon-ssm-agent updated successfully to 2.3.714.0
  • Systems Manager 画面の Managed Instances 一覧にいれば OK

Session Manager Plugin のインストール

PowerShellインストーラーをダウンロードし、起動する。

> invoke-webrequest -uri https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPluginSetup.exe -outfile SessionManagerPluginSetup.exe

> .\SessionManagerPluginSetup.exe

ウィザードが開くので普通にインストールする。 一度ターミナルを再起動し、 session-manager-plugin.exe にパスが通っていることを確認する。

> session-manager-plugin.exe

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

ポートフォワードセッションの確立

AWS Tools for PowerShell を使います。

> Start-SSMSession  -Target "i-************" -DocumentName "AWS-StartPortForwardingSession" -Parameter @{ 'portNumber' = "3389"; "localPortNumber" = "56789" }

Start-SSMSession : i-*********** is not connected. と怒られる。 WSL の AWSCLI からは aws ssm start-session できたので、EC2 問題なさそう。

公式によると Start-SSMSession is not currently supported by AWS Tools for PowerShell on Windows local machines. とのこと。
かなしい。 https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.htmldocs.aws.amazon.com

仕方ないので AWSCLI にします。

AWSCLI セットアップ

chocolatey インストール

> Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Pythonインストール

chocolatey からインストールします。

> choco install python -y
> python -V
Python 3.7.3                                                                                                            

AWSCLI インストール

pip からインストールします。

> pip install awscli

Credential の設定

~\.aws\credential~\.aws\config によしなに設定します

# .aws/credential
[default]
aws_access_key_id = ******************
aws_secret_access_key = **********************
# .aws/config
[default]
region = ap-northeast-1

ポートフォワードセッションの確立(リベンジ)

> aws ssm start-session --target i-04cc97356f6474cf3 --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=56789"

Starting session with SessionId: *******-****************
Port 56789 opened for sessionId *******-****************. 

どうやらうまくいった模様。

いざRDP

f:id:rriifftt:20191001182516p:plain
localhost:56789 に対して RDP します。

f:id:rriifftt:20191001183345p:plain
どうやらつながったようです。
今回はサーバーローカルの Administrator が生きているので、パスワードを入力してみます。

f:id:rriifftt:20191001183041p:plain
ログインできました。

おわり

PowerShell でもできるようになってほしいですね!

おまけ

コマンドを書くのがだるくなったので、指定した Name タグの EC2 インスタンスに対して StartPortForwardingSession する ps1 を作りました。

github.com

Mac の pbcopy と同じことを Windows Subsystem For Linux (ubuntu) でもやりたい

はじめに

最近ギョームマシンをMacからWindowsに変えました。
Windows Server Container を使うかもしれないし、WSL がよくなっているという噂を聞いたので、もしかして Windows を使わない理由がないのではと考えたからです。
ただ、細かいところで Mac での慣れが通用しないことがあり、表題の件もその例の一つです。

pbcopy とは

pbcopy は標準出力をパイプで食わせるとクリップボードにコピーできる便利機能です

ubuntu on WSL では

ぐぐるxsel なるものを使うとよいとあったので試してみます。

$ sudo apt-get install xsel

インストールしたら cat hoge.txt | xsel --clipboard --input のように使うとのことでしたが、以下のエラーとなりました。

xsel: Can't open display: (null)
: Inappropriate ioctl for device

なんだか難しそうなエラーなので他の方法がないか調べてみます。

clip.exe

すると Stackover Flow にたどり着きました。

stackoverflow.com

WSL では Windows 上の exe をシームレスに扱えますので、Windows 標準の clip.exe で事足りそうです。

$ cat hoge.txt | clip.exe

あとはエイリアスを作りたければご自由にという感じですね。
この件はしばらくこれで乗り切れそうです。

宛先ごとに並列でpingする

というものをpythonで作りました。

github.com

pacemakerping RA というものを使い、スプリットブレイン対策のためにNW監視をしているのですが、
宛先ごとにシーケンシャルに ping を撃つという仕様であることから、対象に増減があると timeout などの調整がしんどいというマイナーな事情がありまして。
それを置き換えたいという目的です。

所感としては concurrent.future が便利でした。
また、 Subprocess にも run というメソッドが追加されていて、とても使いやすかったです。

SHIROBAKOとチームビルディングについて

この記事はSHIROBAKOアドベントカレンダーの12日目です。

adventar.org

SHIROBAKOといえば最高なわけですが、なぜ最高なのかは人それぞれでしょう。
ただ、モノづくりの現場を描ききった本作に何かしらのシンパシーを感じている方は多いのではないでしょうか。
ぼくもへなちょこDTMerであり、へっぽこエンジニアだったりするので、感じるものがあります。

現代においては(本質をついているかどうかはともかく)アジャイル開発はある種スタンダードになり、
DevOpsやSREといった発展した文脈も生まれてきている中、それらが原因というわけではないにしても現場に唐突な変化が起きることは少なくありません。

人は基本的に集中を削がれるのを嫌う生き物ですので、場当たり的な変更が繰り返されると疲弊してしまいます。 でもモノづくりは好きだし、携わっていて思い入れも強いプロダクトは成功してほしい、そんなモチベーションで課題やタスクと対峙するという日々を送ったり送らなかったりしています。

そんな感じで心が荒れ気味のとき、SHIROBAKO 2話 「あるぴんはいます!」はキます。

f:id:rriifftt:20181211220444p:plain
あの。。つまり原画から全部新作ということですか???

冒頭から立ち込める暗雲、そして訪れるカオス。やばそうなイキフン。
監督と円さんの口論を経て、なべPに無茶振りされたみゃーもりは緊急会議を開くことにします。

f:id:rriifftt:20181211223331p:plain
今回の作画を直すとして、作業に入る前にもっかいあるぴんやえくそだすっ!のキャラについて、みんなに確認しておくのはどうでしょう?大切なことだと思うんです。

昨今では心理的安全性といった言葉をよく聞くようになりました。チームのパフォーマンスを最大化するためのフレームと捉えていますが、Googleでは 効果的なチームを可能とする条件は何か というリサーチを行ったそうで、この re:Work という記事はちょっとした話題になりました。

rework.withgoogle.com

個人的には、そんなんなくてもどうにかするのがプロでしょっていうのと、やっぱ人間だし必要だよねそういうのっていうのが半々だった時期があるのですが、ないよりはあった方がいいに決まってるじゃんと言われると、まぁ、ぐうの音も出なかったわけです。

モヤッてるときにモヤッたまま進むとモヤッたモノができます。
モヤッたモノに関わった人たちは、少なからずモヤモヤを抱えなければなりません。できればどうにかしたいものです。

どうにかするには、答えは状況によりけりでしょうが、物語の中では対話をすることになります。

f:id:rriifftt:20181211223956p:plain
演出プランを全面的に見直すそうです!

立ち話はコスパがよい と聞いたことがありますが、たしかに話すだけで済むなら簡単です。
対話によって 自分はその場に参加している という当事者意識も働くでしょう。質のよい時間であった方がよいという合理的な判断から、ネガティブであってもポジティブであっても建設的な議論をすることを心がけるでしょう。
そして、よい議論を行うにあたっては、そもそも心理的安全性が前提として必要だったりもします。また、共感も重要な要素となることがあります。

f:id:rriifftt:20181211231159p:plain
うんうん!わかるわかるー!

という共感からの

f:id:rriifftt:20181211231722p:plain
良くも悪くも脇が甘いんですよねー

この山田さんの表情なんかは非常によい例ではないでしょうか。

f:id:rriifftt:20181211232219p:plain
さっきまでこうだった人が
f:id:rriifftt:20181211231722p:plain
こうですからね(しつこい)

そんなこんなで監督の思いがみんなに伝わり、

f:id:rriifftt:20181211232749p:plain

なんやかんやで、あるぴんはここにいます!になるわけです。

re:Workの話に戻ると、チームの課題として以下のことが挙げられています。

従業員はほとんどの仕事をチームの一員として行います。しかし、チームの対人関係に問題が生じたり、メンバーのスキルが適切でなかったり、あるいはチームとしての目標が明確でなかったりすると、生産性の低下やメンバー間の摩擦が生まれるといった問題が生じかねません。

このような課題に対するある種の回答が、このお話には内包されていると思うのです。
人と人がわかり合うニュータイプ的な感覚を共有することと、攻殻機動隊的なスタンドプレーによるチームワークというような、個人的に理想的なチーム。
いいなぁと思うわけです。いいなぁ。

まぁ、そもそも監督ちゃんとしろよという意見ももっともですが、口下手な監督もいますからね。仕方ないですね。
ギャップがあることが問題であるなら埋めた方がいいでしょうね。

見返せば見返すほど発見があるSHIROBAKOですが、今回はこんなところです。

最後に、心理的安全性という観点では監督がスタジオでこんなことも言っていますね。

f:id:rriifftt:20181211233840p:plain
あたしここにいていいのかな?いてよーし!みたいな?

武蔵野アニメーションGoogleかなんかなのかな。

こちらからは以上です。ありがとうございました。

pgpool インストール時に configure: error: header file <libmemcached/memcached.h> is required for memcached support

背景

pgpool-4.0.1 を検証していたら pgpool-4.0.2 が出たのでインストールしてみたところ表題のエラーとなりました。

エラー発生時のインストール手順

pgpoolのインストールはソースから行いますが、インメモリクエリキャッシュを使いたいのでlibmemcachedをインストールします。

# yum install libmemcached

以下の手順で configure してみると WARNING がでます。

# cd /usr/local/src
# curl -L 'http://www.pgpool.net/download.php?f=pgpool-II-4.0.2.tar.gz' -o pgpool-II-4.0.2.tar.gz
# tar xzf pgpool-II-4.0.2.tar.gz
# cd pgpool-II-4.0.2
# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-libmemcached=/usr/lib64/libmemcached.so.11

~略~
configure: WARNING: unrecognized options: --with-libmemcached 

--with-libmemcached オプションは非サポートとなり、 --with-memcached となったようです。
なお、ビルドそのものは可能でした。

オプションを変更して再チャレンジしてみると前述のエラーとなりました。

# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-libmemcached=/usr/lib64/libmemcached.so.11

~略~

checking libmemcached/memcached.h usability... no
checking libmemcached/memcached.h presence... yes
configure: WARNING: libmemcached/memcached.h: present but cannot be compiled
configure: WARNING: libmemcached/memcached.h:     check for missing prerequisite headers?
configure: WARNING: libmemcached/memcached.h: see the Autoconf documentation
configure: WARNING: libmemcached/memcached.h:     section "Present But Cannot Be Compiled"
configure: WARNING: libmemcached/memcached.h: proceeding with the compiler's result
configure: WARNING:     ## ---------------------------------------- ##
configure: WARNING:     ## Report this to pgpool-hackers@pgpool.net ##
configure: WARNING:     ## ---------------------------------------- ##
checking for libmemcached/memcached.h... no
configure: error: header file <libmemcached/memcached.h> is required for memcached support

why?

メッセージの通り libmemcached/memcached.h が存在しないためのようでした。
yum でインストールしたからでしょうか。バイナリのみがサーバー上に存在しています。

# updatedb && locate libmemcached
/usr/lib64/libmemcached.so.11
/usr/lib64/libmemcached.so.11.0.0
/usr/lib64/libmemcachedprotocol.so.0
/usr/lib64/libmemcachedprotocol.so.0.0.0
/usr/lib64/libmemcachedutil.so.2
/usr/lib64/libmemcachedutil.so.2.0.0
/usr/share/doc/libmemcached-1.0.16
/usr/share/doc/libmemcached-1.0.16/AUTHORS
/usr/share/doc/libmemcached-1.0.16/COPYING
/usr/share/doc/libmemcached-1.0.16/ChangeLog
/usr/share/doc/libmemcached-1.0.16/README
/usr/share/doc/libmemcached-1.0.16/THANKS
/usr/share/doc/libmemcached-1.0.16/TODO

libmemcached をソースでインストールしてみる

以下の手順で libmemcached をソースからインストールしてみます。

# curl -L https://launchpad.net/libmemcached/1.0/1.0.18/+download/libmemcached-1.0.18.tar.gz -o libmemcached-1.0.18.tar.gz
# tar xzf libmemcached-1.0.18.tar.gz
# cd libmemcached-1.0.18
# ./configure
# make
# make install

すると、 libmemcached は /usr/local/include/libmemcached にインストールされます。

# updatedb && locate memcached.h
/usr/local/include/libmemcached/memcached.h
~略~

再度 pgpool をビルド

先程のエラーメッセージでは configure: error: header file <libmemcached/memcached.h> ということでしたが、
まさかヘッダーファイルのみをオプションに指定するわけではないだろうということで、ディレクトリを指定してみるとビルドが通りました!

# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-memcached=/usr/local/include/libmemcached
# make && make install

こういうものなんですかね。
とりあえずこれで進めてみます。

翻訳してみた AWS re:Invent 2018: Building SRE from Scratch at Coinbase during Hypergrowth

Sansan Advent Calander 2018 の4日目の記事です。

adventar.org

先日参加させてもらったre:Invent、超たのしかったっす。
その中で面白かったCoinbase社、及びDataDog社によるSREの取り組みについてのセッションをご紹介したいと思います。

www.youtube.com

拙い翻訳で心苦しい限りですが、何かしらの気付きになれば幸いです。

本人より許可いただいています。 Thank You so much.

SREとは何か

新しいものだから定義は変化し続ける。
その中で多くの誤解があるようだ。

これはSRE?

終わりのない火事場?なりやまないオンコール?トイルへの対応?
これらはSREの仕事ではない。

これらは症状であり、この病気に苦しんでいるのなら治癒する必要がある。
それを治癒するのがSREの仕事である。

Devopsとは?

SREは、すべてではないにしても、devopsのオペレーション、及び文化上の要素を満たすことができる

SRE本にもあるように、SREはdevopsの実装の一つであると言われている。
もし既にdevopsをやっているなら、SREはすぐにフィットするだろう。

Key SRE insight #1

計測し、人、組織、システムを改善する

SREはシステムだけを見るのではなく、インシデント発生時のプロセス、あるいはそれから何を学ぶか、組織のプロセスを改善できるか等の側面からアプローチする必要がある。
そのために常に、全てを計測しなければならない。

Key SRE insight #2

受動的ではなく自発的に。トイルを見つけ出し、それを排除する

自宅に火事が起こったら燃え尽きるまで見ているなんてことはせず、消防士を呼ぶだろう。
あるいは、実際に火事が起こるのは嫌なので発生を検知するために火災報知器を設置するなどの積極的な行動をするだろう。
これは問題が大きくなる前に排除するにあたって有効な手段だ。

受動的ではなく自発的に。これはとてもとても重要だ。

トイルとは?
トイルとはスケールしない手動のオペレーションであり、組織とともにどこまでも成長することがある。
成長するトイルを見逃していては組織の成長は阻害されるだろう。
SREはこの問題に対処する必要がある。

Key SRE insight #3

組織的なフィードバック

例えばデータベースのパフォーマンスがよくない状況においてはデプロイを止めた方がいい時がある。
これは適切なフィードバックがあるからできることであり、システムの信頼性を維持するには必要かつ重要なことだから、コミュニケーションには重点を置くべきである。
トップダウンボトムアップの双方で意識されるべきことだ。

Set Early Expectations

SREは新しい概念なので、新しい用語が多くある。
即時的な結果を求めず、ある程度の時間をかけながら始めるのがいいだろう。
でも何から始めればいいか?
Coinbase社では以下の戦略を取ることにした。

Service Level Indicators

何をどう改善すればよいか?何もなければよくわからない。
計測し、現状を理解し、サービスレベルの指標を設定することにした。

作業を進めるときなどには優先度を設定するが、それはどのように設定されるのか、客観的な指標を持つべきである。
その指標にはFour Golden Signalsというフレームが非常に役立つ。
我々はこれらをSLIのコアメトリクスとして採用することにした。

コアメトリクス

データは大量にあるかもしれないが、そのどれもが有用とは限らない。
ビジネスをゴールに向かわせるために本当に大切なメトリクスは何か、それを見極める必要がある。

Four Golden Signals

Four Golden Signalsとは以下のメトリクスである。

  • Latency
  • Traffic
  • Errors
  • Saturation

これらはどんなサービスにも適用できる普遍的な指標であると言える。
また、これは後述するが、人、チーム、組織に置いても適用することができる。

Latency

レイテンシーとはクライアントがWebサーバーからレスポンスを受け取るのにどれくらい時間がかかるのかを示すものであり、顧客の経験に直接的な影響がある。
なぜ遅いのか、それはあなたが計測する方法に依存するので難しい問題である。

ロードバランサーで計測するか、クライアント側でラウンドトリップを計測するか、あるいはサーバー側で計測するか、様々なオプションがあるだろう。
実用的な値を計測するにも複雑になりうる。まぁ、これら3つ全てが取れるならかなりいいよね。

Traffic

トラフィックとは作業量、または試行回数を意味する。
トラフィックはビジネスの価値、規模に大きく関係するが、大量のトラフィックに見舞われた時にシステムのどこかで落ちてしまうことがあるだろう。
なので、しきい値を設定する必要がある。

Errors

成功したリクエストと失敗したリクエストの比率をターゲットとして設定するのは簡単だし、効果的だろう。
例えば昨日はサイバーマンデーで、新たな導線を敷き、大量の消費行動が行われたとして、エラーレートが50%であれば使い物にならなず、0.1%であればそれは良い数字であると言えるだろう。

複雑なシステムではエラーが発生するのは当然起こりうることであるから、ゴールはエラーを排除することではなく、エラーをどこまで許容するかを明確にすることである。
また、このエラーレートを低く維持することをビジネス上の重要な目標とすることが望ましい。

Saturation

TrafficとSaturationは何が違うのか?
Trafficは試行の総量であるのに対し、Saturationは使用可能な総量である。
たとえばWebサーバーのメモリ使用量、DBのディスクスペースといったものだ。
これはソフトウェアそのものではないことから、いつでもどこでも起こりうることなので、指標としてこれまた重要なものであると言える。
ただし、Saturationが発生することはトリッキーな事態であるとも言える。

Humans and the Four Golden Signals

Four Golden Signalsは人やチーム、組織にも適用することができる。

Latencyは、人々がブロッカーを待っている時間に例えることができる。
依存関係のあるタスクを待つなどといった状況のことだ。

Trafficはそれより劇的で、スタックしているチケットの数として見ることができる。

Errorについては、人間は誰しも多かれ少なかれミスをする。
何らかの仕組みが必要となることがあるだろう。

Saturationを人という観点から見たときには燃え尽き症候群のようなものがイメージしやすいのではないだろうか。
燃え尽き症候群は大企業にとって大きな課題である。

Start, Then iterate

you can't finish something that you don't start

これらの課題に対するためには、まずはどこからか始めなければならない。
始めるにあたっては完璧である必要はないし、完璧であることはできない。
シンプルに!

繰り返し、フィードバックを与え、得ることが重要だ。ここに魔法はない。

Spreadsheets are simple, right?

さて、システム、ならびに組織にSLIを適用するにはどうすればいいだろうか。
適切なツールを使うことはやはり効果的だろう。

スプレッドシートはいいぞ(突然の金言)
見やすいし、シンプルだし、シェアしやすく、アクセス性もよい。
簡単にコラボレーションできるしオススメ。

サービスごとのFour Golden Signalをカラムに追加することから初めてはどうだろう。
追加サービスがあるのなら行を追加すればいいし、簡単だ。

SLIs: Defining "done"

システムやサービスにSLIを規定し、スプレッドシートを作成し、運用を開始したとする。
そしてFour Golden Signalsの内のいずれかがSLIに抵触したために作業をしたとして、完了したことを我々はどうやって知ればいいだろうか?

そのためには完了した状態を定義しておくとよいだろう。

まず第一に監視システムや、JIRAのチケットに完了したことを報告する。
次にどのようにして完了させたかを説明するためのドキュメンテーションを行う。

これは常に明確なドキュメントでなくてもよい。
なぜならどのようにこの指標を使用しているか、なぜ重要であるのか、誰が気にするべきなのかは必ずしも明白とは言えないからだ。
(結構ゆるめだなーという印象)

ダッシュボードはあなたの友達だが、注意すべきだ。
ダッシュボードには多くの情報があるはずだが、常に十分な情報があるわけではないので、翻弄されないようにした方がよい。

すでにSLI抵触に関するイテレーションが適切に回っている?それなら問題ない。

start somewhere, this is good place to start.

付け加えておくと、大きな障害を避けるためには予測をすることもとても重要だ。

Specification Documentation

SLIの抵触はCriticalな事態だ。
だからこそ、なぜその指標が重要なのかをドキュメントにしておくとよいだろう。

例えば、元々はELBでレイテンシーを計測していたが、やはりモバイルアプリのクライアント側で計測することが最適であるとして、メトリクスを変更したとしよう。
このような時にドキュメントが重要になってくる。
なぜこの指標が重要であるのか、また、それについての将来のロードマップがどのようなものであるのかを話すことができるからである。

SLIの文化を構築するには仕様文書を作成することに非常に大きな価値がある。
やみくもドキュメント化するのではなく、組織の求めるものは何かを念頭に置き、重要なメトリクスをドキュメント化するとよいだろう。

First SLIs, then promises

あなたは顧客のために何を約束しますか?
また、他のチームが約束していることはあなたに依存しますか?
途方もないことかもしれないが、それについて考える必要があるだろう。

でも恐れることはない。良いPM、良いSREはビジネスの価値を知り、問題解決の能力があり、あなたの問いかけに回答してくれるだろう。
その下地を作るためにも計測し、改善し続けるしかない。

なぜこのようなことをしなければならないのか。
数千のメトリクス、重なる工数、難解な問題は山積みだ。

でも答えは一つ、それは約束を守るためだ。

突然の書籍紹介

Thinking in Promises.
http://shop.oreilly.com/product/0636920036289.do (とてもいい本らしい)

Concerning Promises

promiseには2つのコンポーネントがあり、この場合は人間と機械である。
promiseは人間から機械へ、人間から人間へ、機械から機械へと設定することができる。

それらは常に対等の責任を負う必要はないが、それらの組み合わせの意味を考えることが重要である。
この組み合わせは機能を横断したチーム同士が協力しあっている状態であることが望ましく、より単純な帰結をもたらすだろう。

それは例えばAPIであったり、メッセージキューであったりするかもしれない。

Promises Example

promiseは平易に、明確に明文化すると効果的だ。
それを満たすか、満たさないかがひと目でわかるように。

promiseはSLIに組み込まれることもある。
(SRE本で言うところのSLOがpromiseであるようだ)

例として以下のようなものである。

  • response within 50ms
  • error rate will be > 1%
  • on call 15min

Promise Enumration

各チームはpromiseを列挙したら公式化し、維持なければならない。
また、その機能が果たすべきpromiseを理解していなければならない。

When Promises are Broken...

promiseが破られることは回避できない。
だからこそ、その時に何をすべきか規定しておかなければならない。

インシデントが発生したらどうする?
インシデント発生時のフィードバック方法は規定されている?
継続的なフィードバックは非常に重要である。

Post-Mortems

ポストモーテムには色々とあるが、重要なことは正しい計測、結果の分析、対処である。
そのためには計測した結果を正しく理解し、活用できなければならない。
これができなければポストモーテムはうまく回らないだろう。

Interpreting Incidents

ステークホルダーも交えて共通言語を決定しておくとスムーズに事が運ぶ。
英語なのかフランス語なのか、公式言語は決めておいた方がよい。そのための訓練も重要だ。様々な言語が飛び交う現場は混乱を招くだろう。

また、言うまでもなく発生したインシデントは広く共有すべき。

Mesuring Incident Response

インシデントを定量的、定性的に計測するとよいだろう。
定量的にはインシデントを検知した時間、着手開始時間、リカバリーするまでの時間など。
定性的にはコミュニケーションは適切だったかなど。
これらの継続的なフィードバックは改善に向けて非常に重要である。