ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

入社してから1年半

前回

blog.chaspy.me

いつも通りシュッと書く。

この1年を見返すと、「まぁまぁたいていの仕事は1人でできるようになった」「改善や新しい仕組みの導入もできた」「オンボーディングやExperience mapなどチーム視点での取組もできた」でまぁ60点といったところだ。

この状態から半年たった。すごく密度がある半年だったようには思う。

この期間はいくらか大物を倒して、Software Engineer として幾分か成長したように思う。しんどかったのはこいつ。

quipper.hatenablog.com

あとは SLO について、1人でやっていたところからようやくみんなを巻き込みはじめるフェーズになってきて、コツコツやってきたものが実を結び始めているのも嬉しい。

そしてオンボーディングについて、1年間の総集編のようにシメを、ぼちぼちな規模のカンファレンスで話せたのも、成長の一歩だと思う。(社内でも表彰してもらえた)

blog.chaspy.me

コミュニティ活動についても、SRE Lounge, SRE NEXT, terrform-jp といろいろ貢献できた半年だったと思う。

強く思うのが、Developer だけではない、社内のひとたちとの交流が広がって、それが仕事に活きる、という機会が増えてきたこと。これは僕や周囲だけではなく、人事の方々の社内制度によるものの貢献が大きい。ありがたい。

SRE は他職種との Communication が非常に重要だということを、ひしひしと体感している次第だ。具体的に、今は Reliability Engineering をいかに Product Team に伝播させるか、といったところに注力している。組織を見つめて、サービスを見つめて、しっかりひとを知って、それぞれと丁寧にコミュニケーションをしないと簡単にはうまくいかない。(もちろん今でもすごくうまくいってる!というわけではないが、丁寧なコミュニケーションは心がけているつもり。)

もはやパターン化しつつあるが、Product Team が自己完結的に、Reliability を担保する手段として Design Doc, Production Readiness Check, Schedule Scaling, SLO を導入 / 運用してきた。Developer Team のみんなが優秀かつ思いやりのある人たちなので、いたらない点がありつつもなんとかやってこれていて本当に感謝している。

今後は上記をより強化して、Secure で 安心してできるような制約は最小限にしつつ、Platform の安定性を高めつつ、Product Team が学習コスト低く Reliability Engineering ができるような世界を作っていくつもりだ。

一方まだ足りないと思っているのが Engineering と English。おいおいマジかよそこメインというか、そこじゃん、お前は。みたいな感じでギャグのような話だが、本当の話である。

Engineering に関しては伸ばし方がさっぱりわからない。1つ1つの課題にちゃんと向き合う、というぼやっとした意識づけぐらいしか浮かんでおらず、具体的なアクションも分かっていない。今どれぐらいで、何を学ぶべきで、何をすべきで、どう活かすべきなのか。

コードで問題を解決すること、といっても広いし。なんらか基礎的なトレーニングをしないと問題が問題として解像度高く見えてこないというのもあるかもしれない。

月に一度は Golang でツールを作る、とかを目標にすればいいのかな。手段と目的感あるけど。

英語に関しては7月からオンライン英会話をはじめて、まぁ9割以上、ほぼ毎日続けている。はじめる前に比べると幾分か語彙は増えたし、喋るハードルも下がったし、楽しんだりつらかったりしながらまぁ続けられるかなという程度には習慣化できたことは大きい。

一方質というか、方法についてはオンライン英会話だけではダメで、現状は流れてくる英語を英語として、意味を認識する部分のトレーニングが必要で、リピーティング、シャドーイングをもっとしないといけないと感じている。これについてはようやく PodcastKubernetes Podcast を通勤中聴いてパクパクしている。あとは SRECon の動画なんかも休日に1本見るとかしたい。あとちょうど今日受け始めた SLO に関するトレーニングも動画で英語なので、これもついでに何周かしてシャドーイングの教材にしようと思う。

www.coursera.org

一本道でうまくなんていかないし、うまくいかないことだって、はじめてみないとわからないんだから、大丈夫、ちゃんと進んでいるよ、と自分に声かけて頑張っていきたい。

10月から(チームががっつりわかれたとかではないんだが)主に Global のほうをフォーカスすることになって、仕事上の機会も増えているんだが、英語力がないせいで失っているチャンスは気づいていないだけでたくさんあると思う。それがとても悔しい。

1月にはフィリピンとインドネシアにいくので、みんなとなかよしになってこようと思う。

というわけで次の半年がたつともう2年なんですね。いよいよベテラン感出てきてしまいますね。こまった。

得意な点、Communication や Culture making, Networking なんかは活かしつつも、苦手な点 Engineering, English をより強化して、もりもりバリュー出していきたいと思います。

おわり。

July Tech Festa 2019 で登壇した

はじめに

した。

オンボーディングのひろげかた

昨年の12月にはじめたオンボーディングが、1年という期間を経て、Quipper の文化として十分定着したと言える状態になったと思う。それまでの旅路を、いままで Blog や登壇でしてきたものも含めて、シメることができた。もちろんこれで終わりではなく、これからも俺たちのオンボーディングは続く!

今回 JTF のテーマが「Share! Your Engineering Culture!」だということもあって、ぴったりだと思って Proposal を出したら通った。良い機会をもらえた。

出た質問

  • Q もっとこうしてほしかった、鋭い声、みたいな、厳しめなフィードバックはあったか
  • A 実際にアンケートを見ると、手を動かすコンテンツがあるといい、ドメイン知識とコードとの関係の理解が難しいという意見があった。しかしこれはアクションとしてドメイン知識勉強会を実施して解消している。
  • Q 成果ははかっていないと言ったが、やるとしたらどういう項目が考えうるか
  • A Pull Request を出すまでの時間、Production へコードを投入するまでの時間、を考えたことがあるが、チーム・状況に依存する。半年後とかに状況を確認する Survey をするのもいいかもしれない。が、何を持って「成果」とするかも難しい。(今書きながら思ったのが、オンボーディングはチームビルディングと地続きなので、チームの成果で見られると良い気がする)
  • Q ゴールを設定してから実際に運用するまでにハードルを感じる。難しくなかったか。
  • A そこはあまり苦労しなかった。ゴールはゆるくていいし、実際ゴールを設定してないチームもある。まずはじめてやってみて、あとから改善すればいい、ぐらいのスタンスではじめることのほうが大事だと思う。
  • (終了後)Q. Global, 他拠点のメンバーをつなぐようなオンボーディングをしているか
  • A まったくできていない。Web Developer Team に関して言えば実装上の問題があれば必要に応じて GitHub 上で Communication を取っている。SRE に関しては Global を含め関わるし、それは必要だと思う。具体的な策はないが、各 Product の説明みたいなところは足りてないので、それを説明しつつ、機を見て出張して顔を見て話す、のが効果的かなとは思う。

関心をもってくれてるひとが集まったのもあって、質問も出たというのはよかった。

1人でもこの発表を受けてオンボーディングについて考えはじめたり、あわよくば具体的なアクションにつながるひとがいれば幸いです。

私とJTF

2年前から参加していて、今年で3回目。すごく好きなカンファレンスです。何が好きって言語化は難しいのだけれど。

2年前、まだ SRE になる前に rrreeeyyy さんの発表を聞いて SRE すげーってなったり、nari さんの発表で感銘を受けたりして、いつかこのカンファレンスで登壇したい、と思ったのが今年叶ったというのが嬉しくて、懇親会では主催のハートビーツ藤崎さんにそれを伝えられてよかった。

今回の発表は SRE に関するものではなかったけれど、同じところまであがってこれたなあというのが、後ろを振り返るとたった2年前だけど、随分遠くにきたように感じる。

JTF のおかげでキャリアが築けているといっても過言ではないので、その恩返しができて嬉しい。

前職の先輩が応援にきてくれた

JTF、去年は一応 Proposal を出したんだけど、落ちてしまって、それが確か転職するしないぐらいのタイミングでした。その Proposal で書いた内容が前職の最後の期間にやったことだったので、連絡していて、そのときのメールが gmail で発掘されたので、懐かしくなってよかったらきてねーと伝えたらきてくれました。

元気そうな姿を見せられたのも、よかったなと思います。

Design Proposal は文化を創る

今回一番楽しみにしていたセッション。

Kubernetes の Design Proposal から着想を得て、社内のああゆる提案をちゃんと Document 書こうよということで Design Proposal という形で書いていくと、文化として浸透していくよという話。

sakabe さんのセッション、結構がっつりスライドと内部の実際のissueいったりきたりしていて、生Live感がよかったし、そのやり方自体をぼくも直後の自分のセッションで真似できたのでいい体験ができた。

Conference で Speaker として参加しつつ、他の Talk を聞いて自分の Talk への Feedback となる体験すごくいい。

Wantedly さんは Microservices Monday に遊びにいったり、CTO 川崎さんとオンボーディングの話をしたり、インフラチームの 南さん に業務でやってることの情報交換をしにいったり、Terraformまわりで 田中さん と話したりで、いろいろ交流がある中で、インフラチームリーダーの坂部さんは物理でお会いしたことがなかったので、話を聴けてよかった。

オフィスが近いので何か一緒にできたらいいなあと思っている(だけで動けていない)

ちゃんとセッションを聞いて、TODOに起こしたので、本当に聴けてよかったです。

f:id:take_she12:20191209031906p:plain

Postmortem, Design Doc, Production Readiness Check, Scheduled Scaling といくつか Templates 化しているものもあって、なんとなしちゃんと運用まわってはいるんだけど、ちゃんとドキュメントとして残そうと思いました。

社外の登壇者と合同発表練習

今回、もちろん Quipper 社内でも発表練習を行なったが、45分という長いセッションに2回も3回も付き合ってもらうことに抵抗があったこともあって、いろんな視点からの意見をもらうという意味と、セッションが6並列でなかなか見れないセッションも多いということで、同じ登壇者の方と練習を行なった。

オイシックスさんがショートセッション3連発で出られていて、もともと もりはやさん青木さん とは Terraform meetup で面識があったので、ちょうどいいということで提案して、受け入れてくれました。登壇者だけでなく、彼らの上司の方々も見てくれて、非常に良い体験でした。

また、Twitter で募集したところ、ariakiさんが声をかけてくれて、はじめましてですが練習をして、すごく良いフィードバックをもらえました。

当日は並列で走ってるのもあってなかなかセッションが見れないことも多いし、いい感じに緊張感が保てるので、今後もこういうのはやっていきたい。

カンファレンスの廊下

これ最初聞いた時よくわかんなかったんですが、完全に意味がわかりました。

はてなhokkai7go さんと、廊下ではないですが外を散歩したり、終わったあとビールを飲んだりして最高の体験をしました。

とはいえもともと知っていた間柄というのが前提なので、誰でもできるかというとなかなか難しいですね。

次の登壇

テーマはがらっと変わって、SRE NEXT で SLO について話します。SLO について話すということは、きっと絶対 Site Reliability Engineering についての話もします。

https://sre-next.dev/schedule

SRE なので、SRE についての発表がようやくできるというのも嬉しい。SRE Lounge のスタッフやってることもあってそういう場がないので SRE NEXT 作ったってのもある。こっちも良いカンファレンスになるといいな。登壇者としても、スタッフとしても、あともう少し頑張っていこう。

おわりに

登壇を楽しくやれたのも、すごいよかった。

話したひと、JTFスタッフ、登壇者、参加者、みなさんありがとうございました!また来年も会えたらいいな。

Production Engineer

SRECon みてると「Production Engineer」という Role で登場するひとがまぁまぁいて、まぁ本番環境で Operation をしうるひとで、SREもうそうっちゃそうなんだろうなあと思いつつ、どういう Role なのかを調べてみる。

SRECon EMEA 2019

www.usenix.org

Production Engineer の肩書きのひとを探してみる。

SoundCloud

SRE in the Third Age

SRE in the Third Age | USENIX

Uber

A Tale of Two Rotations: Building a Humane & Effective On-Call | USENIX

Shopify

Network Monitor: A Tale of ACKnowledging an Observability Gap | USENIX

Zero-Downtime Rebalancing and Data Migration of a Mature Multi-Shard Platform | USENIX

Advanced Napkin Math: Estimating System Performance from First Principles | USENIX

Expect the Unexpected: Preparing SRE Teams for Responding to Novel Failures | USENIX

多いな。すごい。

Google

All of Our ML Ideas Are Bad (and We Should Feel Bad) | USENIX

Facebook

Load Balancing Building Blocks | USENIX

Job Description

出てきた会社の JD を漁ってみる。

SoundCloud

Enginnering Levels の記事がなぜかでてきて読んでしまった。

developers.soundcloud.com

で、job のページみたけどいまはオープンになってないようだ。

jobs.soundcloud.com

Uber

あった。

https://www.uber.com/global/ja/careers/list/46494/

読んだけど SRE との違いがよくわからん。

Production Engineering is an organization of engineers who work with our production services throughout their entire life cycle, from design and architecture, through implementation, deployment, and sustaining operation.

よりメタなんだろうか。どうなんだろう。

Senior SRE をみてみる。

https://www.uber.com/global/ja/careers/list/56139/

Production Engineer と同じジャン。。。

Shopify

Production Engineer - Sr Kafka Engineer

Kafka のことばっか注力してる感じだな。

https://www.linkedin.com/jobs/view/1131575400?trk=d_flagship3_salary_explorer&refId=f7bf60f0-b6a3-47c9-a91d-b44c0221c7c8

This position for the Production Engineering team is a hybrid software/system engineer on the Product Sourcing team. Our team covers the disciplines of site reliability engineering, infrastructure engineering, and developer productivity, all to empower merchants and boost their confidence in Shopify’s products.

Site Reliability Engineering だけでなく、なんでもする感じ。

Facebook

www.facebook.com

Production Engineers at Facebook are hybrid software/systems engineers who ensure that Facebook's services run smoothly and have the capacity for future growth. They are embedded in every one of Facebook's product and infrastructure teams, and are core participants in every significant engineering effort underway in the company. Our team is comprised of varying levels of experience and backgrounds, from new grads to industry veterans. Relevant industry experience is important (Site Reliability Engineer (SRE), Systems Engineer, Software Engineer, DevOps Engineer, Network Engineer, Systems Administrator, Linux Administrator, Database Administrator or similar role), but ultimately less so than your demonstrated abilities and attitude. We sail into uncharted waters every day at Facebook in Production Engineering, and we are always learning.

Uber と似たようなことが書いてある。

career のページで SRE を探したけど出てこなかったので、 Production Engineer に統一しているのかもしれない。

おわり

たいした違いはなくて、呼び方の問題ぽい。

Unicorn の Metrics

Rails で使われているアプリケーションサーバUnicorn

bogomips.org

Master Process から fork して Worker Process が実際の処理を行う。

Unicorn Worker Killer

一定回数以上リクエストがくるか、一定量以上のメモリを使用した場合、Worker Process を再起動する君。

github.com

設定

config/unicorn.rb

  • worker_processes: Worker Process の数
  • timeout: timeoutの秒数

prometheus_exporter

Metrics を取得するため、prometheus_exporter を読み込んでいる。

github.com

同僚の takeyama さんの記事

qiita.com

コードをみてみる。

prometheus_exporter/lib/prometheus_exporter/instrumentation/unicorn.rb

github.com

指定された frequency で pid_file から pid を取得して unicorn_collector.collect で metrics を取得して json で返す。

collect_unicorn_stats でとっているのは以下3つ。

  • metric[:active_workers_total] = stats.active
  • metric[:request_backlog_total] = stats.queued
  • metric[:workers_total] = worker_process_count

worker_process_count は直後の private method で定義されている通りで、単純に pgrep で取ってきている。

      result = `pgrep -P #{pid} -f unicorn -a`
      result.lines.count

stats というのがどこからくるかというと listener_address_stats という private method からきていて、tcp であれば Raindrops::Linux.tcp_listener_stats([@listener_address])[@listener_address] を返している。

Raindrops

はてさて Raindrops とは何か。

bogomips.org

raindrops is a real-time stats toolkit to show statistics for Rack HTTP servers. It is designed for preforking servers such as unicorn, but should support any Rack HTTP server on platforms supporting POSIX shared memory. It may also be used as a generic scoreboard for sharing atomic counters across multiple processes.

ほー。

というわけで

Prometheus Exporter で取れる 3つの Metrics は以下

github.com

  • workers_total: 'Number of unicorn workers.',
  • active_workers_total: 'Number of active unicorn workers',
  • request_backlog_total: 'Number of requests waiting to be processed by a unicorn worker.'

active ってのは実際に処理をしているってことなのかな?queued は unicorn に処理されるのを待っているリクエストの数。

request_backlog_total が高い状態が続いた場合、Timeout となってしまいそうだ。

どう解決すればいいのか

  • Unicorn の Pod の Replicas そのものを増やす?
  • Unicorn の Worker 数を増やす?
  • 時間がかかっている処理を高速化する?

Horizontal Pod Autoscaler の Custom Metrics でいけないかな?と思ってググったけどたどり着けず。

kubernetes.io

その他の Metrics

内製の gem が送っているやつがあるようだ。

/proc/pid/stats の cpu time をもってきて、毎秒比較し、それが変化していなければ idle と判定しており、そのほかの metrics はそれに基づいて計算している。 その結果をDatadog に送るもの。

おわりに

request_backlog_total がしばしば増えていて、それによって エラーも出ているようなのでまずは Metrics の理解が大事だと思ったのでいろいろみてみた。勉強になった。さてどうしよう。

英会話2019-10-22

会話 自信を持って話そう Shopping 7 Advanced

わからなかった単語

  • costume noun
    • a set of clothes in a style typical of a particular country or historical period.
  • alligator noun
    • a large semiaquatic reptile similar to a crocodile but with a broader and shorter head, native to the Americas and China.
    • the skin of the alligator or material resembling it.
  • alligator costume
  • bin ???
  • bargain bin: saleのやつが全部ほうりこまれてるやつ
  • price-conscious 価格に敏感な

発音

  • clothes

英語の品詞あらわすやつ

  • Noun 名詞
  • Pronoun 代名詞
  • Verb: 動詞
  • Adjective: 形容詞
  • Adverb: 副詞
  • Preposition 前置詞
  • Conjunction: 接続詞
  • Interjection: 間投詞

動詞の活用

  • past tense: 過去形
  • past participle: 過去分詞

気づき

画像検索するとすぐわかるな。alligator costume。

女の子はpricessになりたくないらしい。そうなの、、、?

Because I don't want to go as a princess.

英会話2019-09-28

ビジネス 会話 Announcing a Pay Cut

Useful Expressions

  • The company is in the red.
  • We are forced to impose a salary reduction.
  • We are left with no other option but to impose a salary reduction.
  • We're going to have to cut your pay by...
  • I know this is not the best news.
  • We didn’t take this decision lightly.
  • As soon as we break even, we will get your salaries back to where they were.
  • How big of a reduction are we talking about?
  • How long do you expect this pay cut to last?

レッスンで使われたセンテンス

  1. We have a definite plan to make that we can recover in three months, so don't worry, your salary will be back to what it was.

レッスンで使われた単語レッスン

  1. drastically-by force, extreme
  2. deficit-shortage
  3. definite-clear

感想

相変わらずセンシティブなテーマが続いているな。。。