twitterのオススメが死んだので、こちらに避難した

一時的なエラーだったようだ

　Twitterしんだ？

SRE本の中で、イベントループスレッドをブロッキングしない、みたいな内容があるんだけど、それについて実際にSREロールのエンジニアは何できるの？みたいな部分で、回答を書いたつもり。

なんかそういうのをもっと言及していきたい。。。

元々は記事のなかで、もっとSRE本内での言及について、こう解釈してこうやってるって話を書いてたんだけど、文字数の都合で第一回からは取り除かれました。文字数の折り合いとか話の流れで必然性が出てくれば、次回以降の連載で触れるつもり。。。

技術評論社さんのWebマガジンで、SREに関する連載が始まりました！
gihyo.jp/article/2023...

位置づけとしては、SRE Workbookの日本版のような立ち位置で、ケーススタディを紹介していきたいらしい

すべてのエネルギーは水から（自ら）ではなく太陽から来ているという発想が求められるところ

MongoDB、_idでソートするときに、ascよりdescの方が普通に早いの、なんでなんだい？

5分のLT、何話せるかなぁ

ゆるSRE勉強会 #1 (2023/08/28 19:30〜) ## ゆるSRE勉強会とは "ゆるSRE勉強会"は、ゆるい雰囲気で肩肘張らずにSRE関連のトピックについて話す勉強会です。 「こんな問題を解決した！」や�...

ゆる〜くSREを語らっていく勉強会誕生しました！
8/28(月)に第一回開催となります🙏

参加枠・LT枠・ブログ枠を絶賛募集中ですので気になる方はポチッと申し込みしてください〜〜〜〜✨

https://yuru-sre.connpass.com/event/292063/

初見の名前だ！あとで調べてみます

こういうタスクのアサインや進め方に名前ってないんですかね。

取捨選択とかプライオリティをちゃんと判断してというのが大事なのはわかってるんだけど、感覚的には投機的に同時に複数プロジェクト回して成功しそうなやつに重心乗せるやり方の方が上手く行くのよなーーー。

すべてのクライアントで同時に発火する危険のある機能だと思ってたので、1億のデバイスが同時に着せかえの切り替えを行った時に、どのAPIにどんなアクセスがあるか、とにかく不安だった。ので、企画の方、ANDROID, iOSのエンジニア混じえて実装や仕様の確認から入らせてもらった。無事リリースできてなにより。

最近、着せかえの時間による自動切り替え機能がリリースされたんですけど（ANDROIDが先行してるかも？）、企画段階からSRE的に超怖かったので、横槍入れさせてもらったりしたのよな。

ACVIのために今からゲーミングPC買うぞ！！！

Slackが死んだ。。。

SREロールを持つとあれもこれも自動化して行きたくなり、結果自動化作業（→プラットフォームの開発運用）で100%工数を使うようになってしまいがち。

DEVロールだと逆に自動化などが後回しなりがち、みたいなやつ。

結局、toilの削減に50%、プロダクトの運用などに50%を費やそうとした時に、dev側のロールにいながらtoilを削減できるのか、sre側のロールにいながらプロダクトの運用が出来るのかという話だった。私が言いたかったのは。

SRE NEXTのネタ探し（？）にSRE本をめくっていたんだけど、SREチームを持つべきかどうかの答えが既に書いてあって、この話やめよ。ってなりました。

SREs often lose track of time and focus on reducing toil forever...

もちろん本人の努力と能力ありき。

うちのSREチームって、まだ歴史が短いので、つい今月初めての退職者が出たんだけど、私の第一印象は「うちのチームに所属してる人が良いところに転職できてよかったーーー」だったな。

色々つらつら書いてみたけど、やっぱこの内容はくそつまらんな。話したいだけで、聞き手は何も持ち帰えることがない

で、結局SREロールやSREチームは必要なわけ？みたいな結論へ繋げていく

なんかこの方向だと微妙かな？

SREチームを持った方が良い状態、持たない方が良い状態という方向から説明した方がわかりやすいか？

そのためには、、、

という話をSRE NEXTでする。

SREチームを持たない方向、持つ方向、どちらの方向から考えても最終的に「機能開発の引力に抗う」プラクティスが必要となる。

より正確には、機能開発を行いながらも、信頼性の改善を続けられる必要がある。

SREチームがプラットフォーム機能開発に集中するようになる。

つまり、機能開発に引力がある。

気がつくと、SREチームが様々な開発者向けプラットフォームを開発運用している状態になる。

つまり当初は下記のように、1hopでユーザーの信頼性を改善していた。
「SREチームの活動→ユーザーの信頼性改善」

しかし、SREチームが熟れて、規模が大きくなると、下記のようになぜか2hopになりがち。
「SREチームの活動→開発者体験改善→ユーザーの信頼性改善」