ツナワタリマイライフ

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

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-24

会話 自信を持って話そう At a Coffee Shop 7 Advanced

わからなかった単語

  • Keep the change: An instruction to a taxi driver, waiter etc. to keep the change from the amount handed over as a tip
  • $9.90 - nine dollarS and ninety cents

感想

なんか急にやたら簡単になったな。。。なんなんだ。。。今までめっちゃ難しかったのに。。。

英会話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

感想

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

英会話2019-09-26

ビジネス 会話 Firing an Employee

Useful Expressions

  • This is not an easy task for me to do.
  • There is no easy way to say this.
  • I'll cut to the chase.
  • I'm really sorry, but we will have to let you go.
  • I'm afraid we will no longer need your services.
  • We have already prepared a letter of recommendation for you.
  • We will give you a severance package.
  • We appreciate the contribution you have made to the company.
  • We appreciate all the hard work you did for us.
  • We wish you well in your future endeavors.

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

  1. He has to tell James that the company has to let him go.
  2. Considering your performance, though you are doing your job, yet you did not meet the company's expectations.
  3. I called you because I have a bad news. This is not easy for me to say but we have to let you go.

レッスンで使われた単語

  1. endeavors
  2. severance
  3. compensation

感想

  • I'm afraid we will no longer need your services.

workingとか仕事ぶりって文脈でyour services っていうんやな。

従業員を解雇する日がくるとは今のところ想像できないなあ。