富士そば 日暮里店と渋谷明治通り店
この記事は 富士そばアドベントカレンダー 2019 9日目の記事です。
がっつり遅刻です。申し訳ございません。
富士そば好き度で言えば先日、ラスベガスで開催された某カンファレンスに参加したのですが、
行く前から「帰ってきたら富士そばに行くんだ。。。」と考える程度の者です。
ラスベガスからはロサンゼルス経由で成田に帰国したのですが、成田から自宅への帰路としては京成スカイライナーで日暮里まで行き、そこからなんやかんやで自宅まで帰るわけです。
去年は巣鴨店に行きましたが、今年は別のお店にしようとGoogle Mapで検索すると、日暮里にあるわけですね。富士そば。
まぁありそうな雰囲気です。
いかにもありそうな雰囲気だなぁと思いつつも、去年もどうせ調べた自分としては、それを見逃すはずはないなぁとか考えていたら割と最近開店したようでした。
ですよねー。
というわけで行ってまいりました。日暮里店。
看板が新しく、いかにもニューウェーブ富士そばという雰囲気。 駅近で使い勝手がよさそうです。
写真にもある通り、 肉骨茶そば なるメニューが見えます。なんだそれは。気になる。
でもあれですよ。合衆国からの帰国一発目の食事で 肉骨茶そば ほどの攻勢に出れる人間なんていませんよ絶対、きっと、たぶん。
そして完全に日和ったぼくはいつも通り紅生姜そばを注文したのでした。
ところで紅生姜天そばっていつ頃からできたメニューなんでしょうね。
10年前くらいに富士そば1号店でカレーうどん3食していた頃にはなかったと記憶しています。
いや、あったかな。。なかったと思う。。
新しめの富士そばらしいカエシで黒すぎない感じのおつゆで、これはこれでアレです。
紅生姜天は鉄板なので、特に言うこともないです。 が、あえて言うなら 最 高 です。
ごちそうさまでした。
とはいえ、なんだかもうやっぱり気になって気になって納期のせまるお仕事が手につかず、困りました。
そう、 肉骨茶そば 。
というわけで翌々日に我がホームであるところの渋谷明治通り店に突撃です。
よかった。新進気鋭の日暮里店が編み出した独自メニューじゃなかった。
逆に言えば新進気鋭感があるこちらのメニューを複数店舗で販売する富士そばは相変わらずなんというかちょっとキてますね。
そして迷わず注文しました。
食べてみると、揚げにんにくが乗った塩豚骨？な感じでして、なんとも言えないデジャブに襲われます。
なんだっけこれ。。食べたことある。。でも麺は富士そばだ。。なんだこれ。。よくわかんない。。という感じでした。
おいしいかおいしくないかは自分にとって重要ではありませんが、不思議なインパクトがあるメニューとなっておりました。
たぶんもう食べないけど。
というわけでごちそうさまでした。
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が便利
- バージョンが低い場合は Run Command から
- 2.3.672.0 以降であることが必須要件
# 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
localhost:56789 に対して RDP します。
どうやらつながったようです。
今回はサーバーローカルの Administrator が生きているので、パスワードを入力してみます。
ログインできました。
おわり
PowerShell でもできるようになってほしいですね！
おまけ
コマンドを書くのがだるくなったので、指定した Name タグの EC2 インスタンスに対して StartPortForwardingSession する ps1 を作りました。
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 にたどり着きました。
WSL では Windows 上の exe をシームレスに扱えますので、Windows 標準の clip.exe で事足りそうです。
$ cat hoge.txt | clip.exe
あとはエイリアスを作りたければご自由にという感じですね。
この件はしばらくこれで乗り切れそうです。
宛先ごとに並列でpingする
SHIROBAKOとチームビルディングについて
この記事はSHIROBAKOアドベントカレンダーの12日目です。
SHIROBAKOといえば最高なわけですが、なぜ最高なのかは人それぞれでしょう。
ただ、モノづくりの現場を描ききった本作に何かしらのシンパシーを感じている方は多いのではないでしょうか。
ぼくもへなちょこDTMerであり、へっぽこエンジニアだったりするので、感じるものがあります。
現代においては(本質をついているかどうかはともかく)アジャイル開発はある種スタンダードになり、
DevOpsやSREといった発展した文脈も生まれてきている中、それらが原因というわけではないにしても現場に唐突な変化が起きることは少なくありません。
人は基本的に集中を削がれるのを嫌う生き物ですので、場当たり的な変更が繰り返されると疲弊してしまいます。 でもモノづくりは好きだし、携わっていて思い入れも強いプロダクトは成功してほしい、そんなモチベーションで課題やタスクと対峙するという日々を送ったり送らなかったりしています。
そんな感じで心が荒れ気味のとき、SHIROBAKO 2話 「あるぴんはいます！」はキます。
冒頭から立ち込める暗雲、そして訪れるカオス。やばそうなイキフン。
監督と円さんの口論を経て、なべPに無茶振りされたみゃーもりは緊急会議を開くことにします。
昨今では心理的安全性といった言葉をよく聞くようになりました。チームのパフォーマンスを最大化するためのフレームと捉えていますが、Googleでは 効果的なチームを可能とする条件は何か というリサーチを行ったそうで、この re:Work という記事はちょっとした話題になりました。
個人的には、そんなんなくてもどうにかするのがプロでしょっていうのと、やっぱ人間だし必要だよねそういうのっていうのが半々だった時期があるのですが、ないよりはあった方がいいに決まってるじゃんと言われると、まぁ、ぐうの音も出なかったわけです。
モヤッてるときにモヤッたまま進むとモヤッたモノができます。
モヤッたモノに関わった人たちは、少なからずモヤモヤを抱えなければなりません。できればどうにかしたいものです。
どうにかするには、答えは状況によりけりでしょうが、物語の中では対話をすることになります。
立ち話はコスパがよい と聞いたことがありますが、たしかに話すだけで済むなら簡単です。
対話によって 自分はその場に参加している という当事者意識も働くでしょう。質のよい時間であった方がよいという合理的な判断から、ネガティブであってもポジティブであっても建設的な議論をすることを心がけるでしょう。
そして、よい議論を行うにあたっては、そもそも心理的安全性が前提として必要だったりもします。また、共感も重要な要素となることがあります。
という共感からの
この山田さんの表情なんかは非常によい例ではないでしょうか。
そんなこんなで監督の思いがみんなに伝わり、
なんやかんやで、あるぴんはここにいます！になるわけです。
re:Workの話に戻ると、チームの課題として以下のことが挙げられています。
従業員はほとんどの仕事をチームの一員として行います。しかし、チームの対人関係に問題が生じたり、メンバーのスキルが適切でなかったり、あるいはチームとしての目標が明確でなかったりすると、生産性の低下やメンバー間の摩擦が生まれるといった問題が生じかねません。
このような課題に対するある種の回答が、このお話には内包されていると思うのです。
人と人がわかり合うニュータイプ的な感覚を共有することと、攻殻機動隊的なスタンドプレーによるチームワークというような、個人的に理想的なチーム。
いいなぁと思うわけです。いいなぁ。
まぁ、そもそも監督ちゃんとしろよという意見ももっともですが、口下手な監督もいますからね。仕方ないですね。
ギャップがあることが問題であるなら埋めた方がいいでしょうね。
見返せば見返すほど発見があるSHIROBAKOですが、今回はこんなところです。
最後に、心理的安全性という観点では監督がスタジオでこんなことも言っていますね。
武蔵野アニメーションは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日目の記事です。
先日参加させてもらったre:Invent、超たのしかったっす。
その中で面白かったCoinbase社、及びDataDog社によるSREの取り組みについてのセッションをご紹介したいと思います。
拙い翻訳で心苦しい限りですが、何かしらの気付きになれば幸いです。
本人より許可いただいています。 Thank You so much.
@niallohiggins @phrawzty hello. your SRE session at re:Invent was so great.
— ~/ (@rriifftt) December 3, 2018
I'd like to introduce it in Japanese, is it OK?
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
- blameless post-mortem
- blameless post-mortemがいいネーミングだとは思わないが。。
- https://techbeacon.com/blameless-postmortems-dont-work-heres-what-does
- data driven post-mortem
ポストモーテムには色々とあるが、重要なことは正しい計測、結果の分析、対処である。
そのためには計測した結果を正しく理解し、活用できなければならない。
これができなければポストモーテムはうまく回らないだろう。
Interpreting Incidents
ステークホルダーも交えて共通言語を決定しておくとスムーズに事が運ぶ。
英語なのかフランス語なのか、公式言語は決めておいた方がよい。そのための訓練も重要だ。様々な言語が飛び交う現場は混乱を招くだろう。
また、言うまでもなく発生したインシデントは広く共有すべき。
Mesuring Incident Response
インシデントを定量的、定性的に計測するとよいだろう。
定量的にはインシデントを検知した時間、着手開始時間、リカバリーするまでの時間など。
定性的にはコミュニケーションは適切だったかなど。
これらの継続的なフィードバックは改善に向けて非常に重要である。