海外カンファレンスで話すということ

まだ何も終わっていないしなんなら準備もまだなんだけども。恐怖とか不安とかを逃避しようとしているのがよくわかるね。 たくさんフィードバックをもらって、スライド構成を見直して、不要なところをカットしたり新しい具体的な例を追加したりした。

20分。何か1つ、誰かたった1人に伝わればそれでいいと思うし、それが別に海外だろうがなかろうが、勉強会のLTだろうが同じ。 経験したことを共有する、ただそれだけなんだよなぁと言い聞かせるも、緊張するものはする。

昨日はSpeaker Receptionで、日本から参加される藤田さんと合流して参加した。 そのとき思ったことを書き留めておく。

最初は席がなくて藤田さんと2人席で話していたところに、ChairのFrancesが来てくれて、挨拶をしてあっちのテーブルに行きなよと促してくれた。 会場はびっくりするほどノイジーで、静かな場所ですら英語を聞き取れないのに、いわんや、といった状況だった。

それでも、みんな本当にいいやつらで、この記事であと何度言うんだろうって感じだが、それは国内でも海外でも規模関係なく同じだ。 何を話すんだい、あなたは？どこからきたの？はじめて？そういった、絶対に誰にでもするであろう会話だけでも、 自分がここにいることを認められた気がしてホッとした。

見に行きたいな、って思いでメモしておく。話したひとたち。

A Tale of Two Postmortems: A Human Factors View Wednesday, 9:10 am–9:55 am Tanner Lund, Microsoft

Availability—Thinking beyond 9s | USENIX

Jason Wik, Jayan Kuttagupthan, and Shubham Patil, VMware

The MTTR Chronicles: Evolution of SRE Self Service Operations Platform | USENIX

VMwareの彼らとはセッション同じ時間じゃんｗ　という話をした。聴けないのが残念だ。

How to Ruin an SRE-Dev Relationship in 3 Simple Steps Raushaniya Maksudova, Google

Our Practices of Delegating Ownership in Microservices World Daisuke Fujita, Mercari, Inc.

Error Budgets in Banks—Challenges & Way Forward Chaitanya Gorrepati and Alex Titlynanov

Lightning Talks | USENIX

Googleの彼女は、私たちが大きなカンファレンスで、あるいは英語（海外）での発表がはじめてだという話をすると、「Sugoidesu」と言ってのけて、Sugoidesuはあなただよなぁという話をした。東京には何度か来ているようだ。

ちなみに Lightning Talks は事前にスライド提出が義務付けられており、1枚15秒 * 20枚スライドで、自動再生されるらしい。ペースが調整できないのはそれはまた別のテクニックが要求されて厳しい。時間を厳密に守るためとはいえ。

強く思ったことは、強くなってまたここに（厳密に同じSRECon Asiaという意味ではなく、海外カンファレンスという意味で）帰ってきたいということだ。

英語はやっぱり全然聞き取れないし、会話をちゃんとできたとは全然言えないが、それでも自分が話したことを汲み取ってくれて、同じ空間を同じ立場で共有できたことを、嬉しく思った。 怠惰な自分の大きなスタート地点だな、と思った。参加して本当に良かった。

英語できるようになりたいなあなんてことを言ってる場合じゃないや。

とまだはじまってすらないが、1日目の朝食をホテルで取りながらこの文章を書いている。 終わったあとはまた別の感想を持つのだろうか。それはまたあとで書こう。

Speaker Reception のあとはメルカリのみなさんにご一緒させていただきお世話になりました。 これもまたいい経験だった。

さぁ、あとちょっと頑張ろう。

etcd clusterをVagrantで立ち上げる

はじめに

立ち上げた。

github.com

vagrant upしてサービス起動すればいいようにはなっている。

coreosにしたかったがboxが見つからなかったのでubuntuにした。

雑記

• systemdの設定ファイル内で環境変数を使うために EnvironmentFile でファイル指定した。IPが違うのでそれはinit処理でいれておくことで対処した。

[Unit]
Description=etcd key-value store
Documentation=https://github.com/etcd-io/etcd
After=network.target

[Service]
User=etcd
Type=notify
Environment=ETCD_DATA_DIR=/var/lib/etcd
Environment=ETCD_NAME=%m
EnvironmentFile=/etc/default/etcd
ExecStart=/usr/local/bin/etcd --name ${ETCD_NAME} --data-dir /var/lib/etcd --initial-advertise-peer-urls http://${ETCD_HOST_IP}:2380 --listen-peer-urls http://${ETCD_HOST_IP}:2380 --listen-client-urls http://${ETCD_HOST_IP}:2379,http://127.0.0.1:2379 --advertise-client-urls http://${ETCD_HOST_IP}:2379 --initial-cluster-token etcd-cluster-1 --initial-cluster etcd0=http://192.168.33.200:2380,etcd1=http://192.168.33.201:2380,etcd2=http://192.168.33.202:2380 --initial-cluster-state new
Restart=always
RestartSec=10s
LimitNOFILE=40000

[Install]
WantedBy=multi-user.target

• systemdのファイル内で改行ってどうするの？ExecStartを改行したい。。。
• 最初の1台目をスタートするとき、他のホストが立ち上がっていない場合起動に失敗するため、init処理ではサービス起動を行わず、3台立ち上がったあとにコマンドでスタートするようにしたが、なんとかならないのか。
• ubuntu、ドキュメントにそって手動でインストールしたけどaptで入ることにあとで気づいた、がまぁsystemdファイルいじりたかったしいいか。。。
• ちゃんと1台でvalue setしたりremoveしたら他でも反映された。すごい。

今後

• Raftの概要と動きを学んで動かす。このへんか。

raft.github.io

• なんらかの言語のクライアントライブラリがあればそれ使って動かしてみる。実際に使いたくなるときに使えるように。

• 2台が落ちたときの復旧方法・動作を確認しておく。1台になるとunhealthyで書き込めなくなるはず。

• 3台落ちたときの復旧方法・動作を確認しておく。1台だけあげようとすると他がいないのであがらないような気も？（timeout時間内に他もあがろうとすると仲間をみつけてあがるような挙動にみえる。これもraftの仕様を学べばわかるか）
• データのバックアップ、リストア方法について。データディレクトリをコピってそのままそこにおけばそれだけで復元するのか、どうなのか。
• etcdctlでできること見ておく

「ソフトウェア開発者採用ガイド」を読んだ

はじめに

読んだ。

ソフトウェア開発者採用ガイド

買ったきっかけはもう忘れてしまった。たぶん誰かがすすめてたか記事で書いてたかしたんだろうと思う。速度でポチるからな。

背景

Quipperではほとんどのエンジニアがなにかしらの形で採用活動に関わることになる。自分と働く仲間は自分で探すといった具合で、採用プロセスに関わることになる。例外なく僕もSREの採用プロセスに関与している。

現在も Senior SRE のポジションをopenしている。

career.quipper.com

まぁ何が言いたいかというと採用活動は難しいし、しんどい。ソフトウェアエンジニアがいきなり（効果的な）採用担当にはなれず、採用活動には何かしらの知識なのか、方法なのかがある。というわけで読んでみた。

いくつかドッグイヤーをつけていた部分を抜粋してみたい。

決断には2種類の答えしかない。採用か、不採用かだ。（p93）

これは kyanny さんが確かどこかにissueで言及していたのが心に残っている。結論には PASS か FAILの2択しかないし、自分は PASS を一度言い渡しながら、その後のプロセスにどうの言うのも違う。

本書にある通り、「採用してもいいけど、私のチーム以外に」もNGだ。

このあたりはわりと採用活動に関わる初期の段階で意識できたので、苦しまずに済んだと思う。

また、これはまたどこかで kechol さんが言っていたけれど、偽陽性を避けているという話をしていた。これもこの本に書いてあったとおりだ。

優秀なひとを逃すことももちろん惜しいが、優秀でないひとを採用してしまうほうが恐ろしいということだ。

迷うというか、積極的に ( QuipperではPASS か FAIL かの判定に Positive か Negative か2択を出す ) Positive が出せないのであれば、それは Negative なのだ。それが早い段階でわからなかったらもっと苦しんでいたかもしれない。

誰を採用すべきかをどうやって判断するかということだ（p95）

原理的にはいたって簡単だ。あなたが探す人というのは

1. 頭が良く
2. 物事を成し遂げる

頭の良さを面接で推し量ることは難しいし、それを知るための、（一見ソフトウェアエンジニアリング、募集するポジションに関係ない）質問をするつもりにはなかなかなれない。ただ、後者の「物事を成し遂げる」という点は自分も見ていると思う。

CV、あるいは面接での会話から、技術力を測るために、技術的に何を成し遂げたか、その過程でどういう思考をしたのかはよく尋ねているように思う。

面接のイントロダクションは候補者をリラックスさせるためのものだ。（p100）

できるだけ相手に力を発揮してほしいとは思うし、人当たりというものは意識しているが、リラックスさせることはまだできていないと思うので、改善したい。挨拶をして、今日の流れや目的などを説明することは相手をリラックスさせることに少しは効果があるとしても。

良いプログラマはすべて再帰とポインタを扱えるべきである（p108）

これは採用プロセスがどうのとか自分への学びというより単に興味深かった。確かに大学時代ポインタである程度のひとが挫折していく。ポインタが理解できることは才能であると言い切る本書の発言は面白かった。

しかし「最後にソートアルゴリズムを書いたのはいつのことですか？」という質問には自分もドキッとしてしまう。

おわりに

この本に書いてある内容は若干古い内容でありつつも、参考になる部分は多く、Quipperの採用プロセスにたずさわるエンジニアも読んでいるひとが多いように思う。そういう意味では共通認識が得られてよかったと思う。

あとは ohbarye さんが hiring support の haruka-oisoさんに、採用観点でエンジニアが読んでおいてほしいと思う本はなんですか？と質問していて、 Work Rules と回答していた。当然 ohbarye さんたちはこれを読んで採用プロセスの改善等行っているわけだが、僕はまだ読めてないので次はそれを読みたい。

ワーク・ルールズ！―君の生き方とリーダーシップを変える

で、会社のslackチャンネル眺めてたらやっぱり ohbarye さんが読んでたからなのでした。ちゃんちゃん。

ohbarye.hatenablog.jp

ディスカッション中心のイベントSRE Sessionを開催しました

はじめに

開催しました！

sre-lounge.connpass.com

SRE Loungeという、各社SREが取組を共有する、プレゼンテーションメインの勉強会があります。これはこれで貴重な知見がたくさんあるのですが、やはり全員参加で、相互交流ができる会も欲しくなってしまいました。また、SREといっても扱う範囲は非常に多岐に渡るため、特定のテーマにしぼって語り合う会をやりたい！と思い、言い出しっぺに法則で立ち上げました。

テーマ選定

SRE Lounge Slackでアンケートを取った上位2テーマを選択しました。

(Public Chennelのものなので特にふせずにそのまま載せてます）

項目の元ネタはSRE 1st Book / Workbookから僕が適当にかいつまんだものです。

2テーマじゃなくて1テーマでもいいんじゃないか、と迷いましたが、実験的な会だったので読めなかったのと、幸運にもSLOとMonitoringはかなり関連性が強いということもあって2テーマでGoしました

アイデア

実はこの会はCloud Native Deep Diveからインスパイアされたものです。

www.meetup.com

実際、私は#4のMonitoring編に参加してこのイベントのやり方のヒントももらったりして非常に感謝しています。

Cloud Nativeの文脈とSREの文脈は、参加者層が微妙に違うような気がしつつも、共通する部分は非常に多いので、今後とも良いシナジーを出せたらいいなぁと思ってます！

公開後1番乗りでDeepDive主催の @jacopen さんが熱い思いで参加申し込みしてくれて嬉しかったですｗ

Welcome Talk

各テーマごとに、会場を温めることと、語彙の共有、トークのネタとしてWelcome Talkを話していただきました！

YahooのtsukaさんよりSLO

SRE Session #1 from Minoru Tsuka

www.slideshare.net

「誰のためのSLOか？」の一言につきます。この言葉はディスカッションでも多く話されたと思います。

メルカリspesnovaさんよりMonitoring

内容が盛りだくさんで後半巻いてもらったのがもったいないぐらい（再演をどこかで！）濃度がぎっしりの資料でした。RED & USEの考え方ははじめて知ったので非常に参考になりました。

ディスカッション

多いに盛り上がり、司会＆タイムキーパーの僕も熱中して時間がすぎてしまうほど（反省）。

それぞれ20分じゃ足りない感じだったので今後の改善につなげていきたいと思います。

感想

概ね多くのひとからも好意的なフィードバックをいただいており、本当にやってよかったと思います。

SRE本に書いている内容をどの会社も実践できているわけではなく、そのレベルや考え方も様々。それをディスカッションすることで良い点悪い点を議論し、今後のみなさんの実務に結びつく機会になっていれば幸いです。

振り返りと今後

事後アンケートを実施し、たくさんのフィードバックをいただきました。参加者のみなさんありがとうございました。

みなさんのフィードバックのおかげで、次回開催も決定しました！次回は6/5に開催を予定しています。（会場まで決定しており、準備中）

プレゼン形式のSRE Loungeと毎月交互でやっていきたいと思っているので今後もよろしくおねがいします！

最後に会場提供してくれたQuipper... のhiring-supportのみなさんとSRE @motobrewさんお手伝いいただきありがとうございました、この場を借りてお礼申し上げます。

"Graphic Recorder 議論を可視化するグラフィックレコーディングの教科書"を読んだ

読んだ。

Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書

クローズドでやっている勉強会で友人氏がこれを実践してみたって発表をしていたので読んでみた。

docs.google.com

この本、何が良かったって作者の思想がとても良かったです。

はじめに　より

本書が目指す世界、それは、年功序列、事なかれ主義、責任者不在を打ち破り、凝り固まった後ろ向きな空気に流されずに、どんなに難しくて気まずい関係の会議でも、諦めずに思考停止しない世界です。今もこの瞬間に日本の何万と行われている不毛な会議が、グラフィックでの記録によって前向きな思考と関係性に変えられたら少しずつ世界は変わるのではないか。そんな想いをこめて本書を届けます。

グラフィックレコーディング自体は単なる1手法に過ぎません。しかし、その手法が解決しようとしている問題が、未来が素晴らしいものだなと思いました。そしてまさにグラフィックレコーディングは現状の"会議"の問題を解決しうるツールだと思います。

また、おわりに、でもテクノロジーの進化に伴いグラフィックレコーディングの未来について語られていて、

齟齬の生まれる場所は、複雑で曖昧な感情や関係性の中にあり、音声情報だけでは決して読み取れません。情報の的確な整理はできえも、相手の考えに共感して協力しようと信頼しあえる関係性を生み出すような場づくりは難しいでしょう。そうなった時に、未来のグラフィックレコーダーは、正確性が問われる事実関係は機械に任せて、その分浮いた時間で参加者の一歩先の理想を想像しながら新しい「視点」を提供するようなグラフィックを描くことが、今以上に求められるのではないでしょうか。

と、やはりグラフィックレコーディングの持つ価値は飽くまで議論の活発化・明確化だとわかった上で、そのようなツール・手法が今後も必要になっていくという点を示しています。

グラフィックレコーディングとは

会議を図や絵を用いて内容を整理することにより、

• 一覧性の向上 / グラフィックによる具体化による参加者間の齟齬を最小化する
• 参加者同士という視点から問題対私たちという構図を強制することによる議論を建設的にする

といった効果をもたらす考え方 / 手法です。

グラフィックレコーディングの本質的な点は上記だと私は感じました。

グラフィックレコーディングのある日常

私は一通り読んだ後、絵・アイコンをすばやく・わかりやすく描く技術を伸ばすかと言うと多分やらないと思います。（今は困っていないので）

そもそも私は会議自体そこまで多くないのですが、例えばチーム内で情報の共有をするときはホワイトボードをよく使います。 特に複雑なアーキテクチャの理解や、運用手順の理解をするとき、図は非常に有益です。そういう意味で普段からグラフィックレコーディングを実践していることになります。

（この本がより一般的・汎用的にしていることを理解した上で）私たちソフトウェアエンジニアはおそらくペンで文字を書くよりキーボードで打ったほうが速いと思います。そのため、実際の私たちの現場では「事前に共有事項を絵、あるいはGitHub Issueに（構造化して）書いておく」「実際に話しながら、ホワイトボードに書いたり、GitHub issueに追記したりして会議を記録する」「会議のゴールが達成できたら終わり」って感じの流れが多いです。

本書の例では絵では描ききれない点は文字で補っていましたが、おそらく速度に限界がある（可読性とトレードオフ？）と思っていて、その点はキーボードによる打鍵での文字情報の記録とうまくコラボレーションできればいいなと思いました。

前述の通り、私は仕事をどう行なうか1人で考えるときにノートとペンでまず書きますし、例えば近くのチームメンバーに何か説明するときに使うこともあります。日常的にグラフィックレコーディングを使っていました。名前を与えるということは大事ですね。

おわりに

グラフィックレコーディングという手法にだけ焦点をあてるのでなく、解決したい課題に強くフォーカスして伝えていた点が非常に良いと思いました。この方法で会議を効果的なものにすると同時に、「この会議はなにを解決するのか？」という点にフォーカスしたり、同様の解決ができる別の手法と組み合わせて使ったりして、日本の無駄な会議が減ることを願っています。

2019年1Q振り返りと2Q

なんか1Qどうするの表明もしてないしなんか年始に毎週ブログ書くとかいって書いてないしまぁそんなもんだよね。

1月から3月、冬休み明け気合を入れて、というのもあったし、単純にできることが増えた、というのもあったが、いい意味で忙しくできていたと思う。 仕事を通じて技術的に新しいことを学んだり（特にCDNについて学べた）Vimの勉強会にうっかり参加してVim力をあげたり。 あとは会社ブログに少しずつ出していこうと思っているが、Microservicesの受け入れ準備的なものを子issueに分解して少しずつ進めていっている。

2月はフィリピン・マニラに同僚の結婚式ついでに1週間マニラオフィスで働いて「基本的にすべて一発で英語が聞き取れない」という事実を持って返ったりしました。

結局この3ヶ月で何ら具体的に英語学習に関するアクションができていないんですが、いよいよやろうかなと思えたのはSREConのCFPが通ったことですね。 もともと12月から2月ぐらいにかけてオンボーディングに取り組んでいて、一通り済んだ＆そういえばグローバルメンバーもなんか興味持ってたってことで 英語でサマリまとめてshareしよう、ついでにSREcon出すだけ出そう！と思ったら通ってしまったという感じです。6月シンガポールです。

www.usenix.org

国内ですら大きいカンファレンスの登壇経験ない（小規模勉強会でのLT程度の経験しかない）のにいきなりマッチョなことしてしまったなぁと思いつつ、まぁ順序なんぞないし、前向きに楽しんでいこうと思っています。 Talkは内容だけで審査するため、個人や会社を特定できる情報は書かないでください、とあったのが、公正でいいなぁと思いました。 LTの募集もOpenしてるみたいなので誰か一緒に行きましょう。

We will accept lightning talk proposals starting on Friday, March 22, 2019

英語の勉強ですが、発音を直してもらいながら学ぶ何かをしたいというのと、Listingの訓練をしたい。で、どうするかって感じですが、 後者に関してはSREconの過去の発表を何度も見て聴くというのをやるつもり。YouTubeの字幕機能でなんとか。英語学習に関しても便利な世の中になりましたね。 発表資料どんなもんかな？っていう勉強もかねて。前者はどうすっかな。そういうていで英会話的なsomethingやるしかないな。

Readingは最近を読んだりもしてるけど、技術学習で英語から学ぶ割合を増やすしかないと思う。さいわい日本語でも学びきれないほど豊富に情報があるけれど、やっぱり新しいこと、これからなこと（特にKubernetes, Microservices, Service meshなんか）は英語のほうが早いし多い。こっちをがっと読んでばっと要点をとってくる筋力をつけたいと思う。

とはいえ、英語に懸念がありつつも、大事なのは中身だと思うので、今回SREで実施した内容に加えて、SREを越えて適用するには、みたいなところもトークに入れ込もうと思っています。 なんか各国のエンジニアチームもオンボーディング重要だと思ってるけどどうしよう？って悩んでるみたいで、「おれの取り組み共有するぜー」って言ったら「うちらも悩んでるのだ！Let's join us！」みたいになってグローバルのオンボーディングyatteiki隊に加入してしまったのでこれを活かしてなんかいい感じにTalkのネタ増やしていきたいと思います。

それと同時に、ちょっと2Qはある程度このTalkと今やってる業務にフォーカスする必要があるなぁと思いました。 ついつい興味が散ってなんでもかんでも手を出しがちな性格なので、意図して時間の使い方を制御しよう、と思ってブログを書こうと思った次第。

登壇や発表より、目の前の課題を解決することが大事なことはわかっていますし、組織のことと同じだけ、技術力が大事なこともわかっています。

それでも僕はOSSや、コミュニティのおかげで今のポジションになれたので、今年はコミュニティ活動もやっていきたいと思っています。

コミュニティのおかげでSREを目指すことができたので、コミュニティに恩返ししたいという気持ちがあるっぽい。

— 🤔 (@chaspy_) March 14, 2019

SRE Loungeは運営として携わっていますが、4月はSRE Sessionを企画したり、あと今年中にビックなことができたらいいなぁと画策していたりします。

sre-lounge.connpass.com

技術的には、メタなところではクリーンコード的な視点でちょっと学ばないといけないなぁと思っているのと、 やっぱり作業環境の"速度"(Vim, terminalなど)がまだまだ足りないのでそこは継続的にやっていきたい。 経験が足りないのはどうしてもしょうがないので知識＋目の前の問題を解決しながら学ぶってやっていくしかないね。

おしまい。

"失敗から学ぶRDBの正しい歩き方"を読んだ

読んだ。

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

知見の宝庫。著者の曽根さんが本書を書く理由を「知見を後の世代につなぐため」といったことをおっしゃっていて（Twitterから見つけきれず。。。）本当にありがたいと思いました。この本自体も様々な参考となる本が紹介されていて、さらに次の学びへつなげることができるようになっています。

本書の中では、「フラグの闇」が印象的でした。これまで削除フラグにより論理削除と呼ばれるものはよく見てきたし、特に違和感を持っていませんでした。しかし、クエリの複雑化（かつ、影響が広範囲に及ぶ）、UNIQUE制約が使えなくなる可能性がある、カーディナリティが低くなる、といった理由があげられており、便利なのはわかる反面デメリットもあることを学びました。

そしてメタな考え方として「DBには事実のみを保存する」（＝状態を持たせない）というのが今まで考えていなかった考え方でした。

削除フラグが利用したくなるシーンでも、まず他の方法でできないか検討してからデータベースで状態をもたせるか検討したほうが良さそうですね。

最後に目次をのせて自分の中のINDEXに保存して終えようと思います。

• 第1章 データベースの迷宮
• 第2章 失われた事実
• 第3章 やり過ぎたJOIN
• 第4章 効かないINDEX
• 第5章 フラグの闇
• 第6章 ソートの依存
• 第7章 隠された状態
• 第8章 JSONの甘い罠
• 第9章 強過ぎる制約
• 第10章 転んだ後のバックアップ
• 第11章 見られないエラーログ
• 第12章 監視されないデータベース
• 第13章 知らないロック
• 第14章 ロックの功罪
• 第15章 簡単過ぎる不整合
• 第16章 キャッシュ中毒
• 第17章 複雑なクエリ
• 第18章 ノーチェンジ・コンフィグ
• 第19章 塩漬けのバージョン
• 第20章 フレームワーク依存症