@maruloop.bsky.social
SRE@LINE
twitterのオススメが死んだので、こちらに避難した
21.12.2023 05:44 — 👍 1 🔁 1 💬 0 📌 0一時的なエラーだったようだ
07.11.2023 00:03 — 👍 0 🔁 0 💬 0 📌 0Twitterしんだ？
07.11.2023 00:02 — 👍 0 🔁 0 💬 1 📌 0SRE本の中で、イベントループスレッドをブロッキングしない、みたいな内容があるんだけど、それについて実際にSREロールのエンジニアは何できるの？みたいな部分で、回答を書いたつもり。
なんかそういうのをもっと言及していきたい。。。
元々は記事のなかで、もっとSRE本内での言及について、こう解釈してこうやってるって話を書いてたんだけど、文字数の都合で第一回からは取り除かれました。文字数の折り合いとか話の流れで必然性が出てくれば、次回以降の連載で触れるつもり。。。
25.09.2023 04:21 — 👍 1 🔁 0 💬 0 📌 0技術評論社さんのWebマガジンで、SREに関する連載が始まりました！
gihyo.jp/article/2023...
位置づけとしては、SRE Workbookの日本版のような立ち位置で、ケーススタディを紹介していきたいらしい
すべてのエネルギーは水から（自ら）ではなく太陽から来ているという発想が求められるところ
24.08.2023 10:31 — 👍 16 🔁 7 💬 0 📌 0MongoDB、_idでソートするときに、ascよりdescの方が普通に早いの、なんでなんだい？
16.08.2023 09:32 — 👍 0 🔁 0 💬 0 📌 05分のLT、何話せるかなぁ
04.08.2023 00:03 — 👍 0 🔁 0 💬 0 📌 0
ゆる〜くSREを語らっていく勉強会誕生しました！
8/28(月)に第一回開催となります🙏
参加枠・LT枠・ブログ枠を絶賛募集中ですので気になる方はポチッと申し込みしてください〜〜〜〜✨
https://yuru-sre.connpass.com/event/292063/
初見の名前だ！あとで調べてみます
03.08.2023 02:09 — 👍 0 🔁 0 💬 1 📌 0こういうタスクのアサインや進め方に名前ってないんですかね。
03.08.2023 02:01 — 👍 0 🔁 0 💬 1 📌 0取捨選択とかプライオリティをちゃんと判断してというのが大事なのはわかってるんだけど、感覚的には投機的に同時に複数プロジェクト回して成功しそうなやつに重心乗せるやり方の方が上手く行くのよなーーー。
03.08.2023 02:01 — 👍 1 🔁 0 💬 1 📌 0すべてのクライアントで同時に発火する危険のある機能だと思ってたので、1億のデバイスが同時に着せかえの切り替えを行った時に、どのAPIにどんなアクセスがあるか、とにかく不安だった。ので、企画の方、ANDROID, iOSのエンジニア混じえて実装や仕様の確認から入らせてもらった。無事リリースできてなにより。
02.08.2023 13:27 — 👍 4 🔁 0 💬 0 📌 0
最近、着せかえの時間による自動切り替え機能がリリースされたんですけど（ANDROIDが先行してるかも？）、企画段階からSRE的に超怖かったので、横槍入れさせてもらったりしたのよな。
02.08.2023 13:24 — 👍 5 🔁 0 💬 1 📌 0ACVIのために今からゲーミングPC買うぞ！！！
28.07.2023 12:49 — 👍 1 🔁 0 💬 0 📌 0Slackが死んだ。。。
27.07.2023 09:33 — 👍 0 🔁 0 💬 0 📌 0SREロールを持つとあれもこれも自動化して行きたくなり、結果自動化作業（→プラットフォームの開発運用）で100%工数を使うようになってしまいがち。
DEVロールだと逆に自動化などが後回しなりがち、みたいなやつ。
結局、toilの削減に50%、プロダクトの運用などに50%を費やそうとした時に、dev側のロールにいながらtoilを削減できるのか、sre側のロールにいながらプロダクトの運用が出来るのかという話だった。私が言いたかったのは。
25.07.2023 12:13 — 👍 0 🔁 0 💬 1 📌 0SRE NEXTのネタ探し（？）にSRE本をめくっていたんだけど、SREチームを持つべきかどうかの答えが既に書いてあって、この話やめよ。ってなりました。
25.07.2023 12:11 — 👍 1 🔁 0 💬 1 📌 0SREs often lose track of time and focus on reducing toil forever...
25.07.2023 00:59 — 👍 0 🔁 0 💬 0 📌 0もちろん本人の努力と能力ありき。
23.07.2023 11:45 — 👍 0 🔁 0 💬 0 📌 0うちのSREチームって、まだ歴史が短いので、つい今月初めての退職者が出たんだけど、私の第一印象は「うちのチームに所属してる人が良いところに転職できてよかったーーー」だったな。
23.07.2023 11:44 — 👍 5 🔁 1 💬 1 📌 0色々つらつら書いてみたけど、やっぱこの内容はくそつまらんな。話したいだけで、聞き手は何も持ち帰えることがない
22.07.2023 07:58 — 👍 0 🔁 0 💬 0 📌 0で、結局SREロールやSREチームは必要なわけ？みたいな結論へ繋げていく
22.07.2023 01:55 — 👍 0 🔁 0 💬 0 📌 0なんかこの方向だと微妙かな？
SREチームを持った方が良い状態、持たない方が良い状態という方向から説明した方がわかりやすいか？
そのためには、、、
という話をSRE NEXTでする。
SREチームを持たない方向、持つ方向、どちらの方向から考えても最終的に「機能開発の引力に抗う」プラクティスが必要となる。
より正確には、機能開発を行いながらも、信頼性の改善を続けられる必要がある。
SREチームがプラットフォーム機能開発に集中するようになる。
つまり、機能開発に引力がある。
気がつくと、SREチームが様々な開発者向けプラットフォームを開発運用している状態になる。
つまり当初は下記のように、1hopでユーザーの信頼性を改善していた。
「SREチームの活動→ユーザーの信頼性改善」
しかし、SREチームが熟れて、規模が大きくなると、下記のようになぜか2hopになりがち。
「SREチームの活動→開発者体験改善→ユーザーの信頼性改善」
