Findy社が開催していた開発生産性カンファレンス 2024に6/28, 6/29の両日行ってきました。 dev-productivity-con.findy-code.io 最近、Four keysなど開発生産性に関する情報が巷に増えてきて、開発生産性とはなんぞや？と改めて考えるようになりまして、何かの助けになることを期待して参加させていただきました。 スポンサーブースいっぱい！たのしい！ 最初にスポンサーブースをちらと覗いてからセッション聞きに行くかーと、スポンサーブースの部屋を覗いてみたらあらビックリ、もの凄い数のスポンサーブースでした・・・！ 総勢37社のスポンサーブースが展開されていたということで、それだけで圧倒されてしまいました。 また、スポンサーブースのスタンプラリーがあり、スタンプを集めることで最大３回回せる巨大ガチャもあり、そういった様子を見てるだけでもワクワクするような

つい最近GitHub Actionsをいじっていた時のお話です。 GitHub ActionsにはReusable workflowsと呼ばれる再利用可能なワークフローの仕組みがあります。 docs.github.com 例えば複数のリポジトリで同じワークフローを実装している場合に、何かを修正する必要が出てくると全てのリポジトリに修正の手を入れるのは面倒ですよね。 そんな時にReusable workflowsを利用して同じ処理を再利用可能な形にしていれば、それぞれのリポジトリが参照している一つのワークフローを修正するだけで済むようになります。楽チンです。 そのように依存関係を整理できる便利なReusable workflowsですが、つい先日お仕事で新しいリポジトリを用意してReusable workflowsの一つに参照したところ、以下のように怒られました。 つまりは呼び出そうとしたw

SRE界隈の隅っこでワチャワチャやっているしょっさんです。 今色々やっているコミュニティ活動についてのお話を書き留めておきたいなと思ったので、ここにパパッと書いていきます。 今までについて 今までのコミュニティ活動の関わりについては以下のしずかなインターネットの記事として書きました。 sizu.me そんなこんなで「ゆるSRE勉強会」の運営に関わらせていただいているのですが、せっかく再びコミュニティ活動始めたなら色々やってみっか！ってことで色々走らせてみました。 SRE Magazine SREに関する記事を探すと様々なところに散らばっており、SRE Weeklyみたいな集約された場所があると面白いよな〜ということでエイヤの精神でやってみました。 sre-magazine.net 「るびま」を参考に構成しているWebマガジンなのですが、最近第１号が発刊することができました。で、始めるにあた

今回は御縁があってKDDIアジャイル開発センター（KAG）さんとMIXIの合同イベントに登壇いたしました。 mixi.connpass.com 今回のテーマが「SRE観点での技術負債」ということで、私の方からは以下のようなお話をさせていただきました。 speakerdeck.com このブログではいつものようにライナーノーツとしてお伝えしきれなかったところなどを書いていこうかなと思います。 技術負債とは？ まず、このイベントのテーマである「SRE観点での技術負債」ってなんだろう？と引っかかったので、ここをブレイクダウンしていかないと自分の中でブレてしまいそうだなと思いましたので、技術的負債の定義を経てSRE観点の技術的負債の定義からさせていただきました。 技術的負債については色々な説があると思いますが、なるたけ新し目の説を扱おうということで（古いと時流と合わない可能性が高い）、「Defin

去年に引き続き、今年も社のカンファレンスに登壇させていただけました。 techcon.mixi.co.jp 去年と違い、今年はオフラインで会場にいらっしゃった方の前で初めて体験するパネル・ディスカッション形式ということで非常に緊張いたしました。 この記事では喋ったことの補遺というかライナーノーツみたいなことを書いていこうと思います。 他のチーム、職種の方との連携のコツ、取り組み 自分回答はこちら 「職種ごとに目線が違うのでそこを意識すること。非エンジニアの方とやり取りをする場合にはエンジニア間でしか通じない単語などを使わない。あとはベタにteam geekにも書いてあるHRTを大事にする。」 会場でも話しましたが、目線を揃えるということはサイトリライアビリティワークブックの18章にある「目標を揃える」と同義です。SREsが信頼性を尊ぶように、QAチームなら品質、ビジネスチームなら売上が目標

気付いたら2024年が始まって３ヶ月記事を書いていなかったことに気付いたので、慌てて書いております。 ということで、2/14にFindyさんが主催の勉強会に登壇させていただきました。 findy.connpass.com 今回はSRE × セルフ・アウェアネスという題材でお話させていただきました。 speakerdeck.com 登壇のお話を頂いたときに「何の話をしようかな・・・」と考えたのですが、自作k8sコントローラを作った話とセルフ・アウェアネスの話と悩んだ末に、後者の話にしました。 正直、前者の話をしてもk8sを扱ってない人からするとピンと来ない話でしたし、もう少し汎用性のある話をしたかったというお気持ちで選択。 さて、今回のセルフ・アウェアネスの話ですが、そもそものきっかけはSREConでの「The Secret Weapon for a Successful SRE Caree

今年ももう年の瀬ですね。30歳を越えてからというもの、年々時間の経つのが早く感じられて恐ろしくある今日此の頃でございます。 というわけで今年も一ヶ月毎に振り返ってみましょう。 １月 いきなり病気からスタートだったのですが、年末年始コロナにかかってダウンしておりました。いやー、コロナに初めて罹ったのですが辛いながらも 扁桃腺炎 > コロナ という感じでした。あえて分類するとすれば瞬発的な辛さは扁桃腺炎がダントツで、持続的な辛さはコロナで喉の痛みといった症状は一緒だけれども痛みの度合いは扁桃腺炎が段違いでしたね・・・コロナはコロナで、１月中は咳が止まらなくて生活のしづらさが目立ちました。 何はともあれいい年齢の人間になったので、病気には気を付けたいものです。 さて、１月の大きなトピックといえば年始早々のCircleCIのセキュリティインシデントですね。 circleci.com 弊チームでもご

この記事はMIXI DEVELOPERS Advent Calendar 2023の１８日目の記事です。 今回はやったことある人が多そうな本番DBのデータをステージングDBに同期させる仕組みを作ったお話になります。 前提のお話 何故作ったのか？ですが、データ数の問題から開発・ステージング環境では発生せず本番環境では発生するような表示上のバグが数は少ないですが存在し、そういった問題を早期に発見するために対応できませんか？と相談されたことがきっかけで同期の仕組みを作ることになりました。 また、ステージング環境ではQAチームによる自動テストが動いており、本番環境データが同期されていればより潜在的な問題の発見に役立ちそうですね。 ここから詳しい説明に入りますが、DBはCloud SQL for MySQL v5.7に準拠した内容となっております。 作る さて、ここから作るフェーズに入っていくのです

GKE / k8s、まだまだ分からんことが多くて学び甲斐があるなぁとしみじみ思っている今日この頃。 今回はそんな中で掲題のコスト最適化のお話をします。 要約 本番環境が載っていないクラスタは自動スケーリング プロファイルをoptimize-utilization（使用率の最適化）やっとくと良い 特に短いスパンでのCronJobを動かしているとコスト改善の可能性大 前提 GKEを使ってサービス運用している時に気になるのはやはりコストですよね。私が関わっているサービスでもコストをもう少し下げようといった声が大きくなり、その中でも大きな割合が割かれているGKEに注目が集まりました。 こういう時、まず手を付けるのは開発環境周りですね。Develop, Staging環境などを一つのクラスタで管理しており、ここなら最悪ぶっ壊しても問題なく着手しやすいのでここからやっていきます。 やったこと やったこ

この記事はSRE Advent Calendar 2023の１日目の記事です。 今回は業務で「GitHubリポジトリをあるorganization（以下、org）から別のorgへ移行させる」ということをやったので、その時のお話をさせていただきます。 何をするのか？ もう少し、何を目標としていたのか？を具体的に書くと、現在リポジトリ群が所属しているorgからGitHub Enterprise Cloud（以下、GHEC）配下に作成したorgへ移行させる、ということをやろうとしたお話になります。 GHECに移行するモチベーションとしてはGitHub Copilot for Businessが利用できたり、SAML SSOを利用できたりするというメリットを受けることが出来るからですね。（開発者にとってはCopilotが理由として大きいかも） 移行前の状況 移行前は以下のような状況でした。 自分が

Xでのサービス関連ポストをSlackに安易に流すととんでもないことになるぞ 何が起こるか？ ビジネス側からの要望で「Xでうちのサービスのことつぶやいているポストがあったら適宜Slackに流してくれない？」が発生することは結構あるかと思います。 GASなり、IFTTTなりで X -> Slack に流すことになると思いますが、まずこういった形で流したSlackの投稿は第三者が消すことは出来ません。（※消せるなら教えてくだせぇ） で、あまり何も考えずにXの検索クエリをサービス名のみでやってしまうとあら大変、削除できないセンシティブ画像の波がやってきます。 ここで「検索クエリ気を付ければ大丈夫でしょ？」と思う方もいらっしゃるかもですが、割と弾こうと思っても弾けないものでございます。 例えば、実際にあったのは同一名サービスのドメインで弾いたり、言語設定を日本語のみのポストに絞ったり色々手は尽くした

今年もState of DevOps Reportが発表されましたね。ということで、ザザッと全体を読んで気になったところなどピックアップして読み解いてみました。 全文が気になる方は以下からPDFをダウンロードしてみてください。 cloud.google.com 今年の調査主軸 組織の業績 組織は収益だけでなく、顧客のため、さらに広範なコミュニティのために価値を生み出さなければならない チームパフォーマンス アプリケーションまたはサービスチームが価値を創造し、革新し、協力する能力 従業員の幸福 組織やチームが採用する戦略は、従業員にとって有益なものでなければならない。すなわち、燃え尽きを減らし、満足のいく仕事体験を育み、価値あるアウトプット（つまり生産性）を生み出す能力を高めることである。 今回は上記３つの成果達成に対しての調査となった。 調査結果短評 生成的な文化を持つチームは、組織のパフ

SRE NEXT 2023で「QAと共に築く、機能性を通じた信頼性担保への取り組み」というタイトルで登壇させていただきました。 sre-next.dev 今回はQAとのコラボレーションとコミュニケーション・コラボレーションについて、のようなテーマを発表しました。 speakerdeck.com 発表で伝えたかったこと SRE NEXTでCFPが始まった時に「あまり他の方が発表されてない内容」かつ、「SRE NEXT 2023の価値観に合う内容」にしようと決めました。 これは別に通りやすくするためではなく、単純にあまり発表されていない内容 = もっと界隈で知見を広げなければいけない分野なので、・カンファレンスのテーマに沿わないと折角運営の方々が立てていただいた価値観を蔑ろにしてしまうのでは？と考えたためです。 この２つの柱は外すことがないように肝に銘じて、まず今までに自分が行ったSREプラ

SRE NEXT 2023に登壇者として参加させていただきました！ 大きな舞台で貴重な経験をさせていただいたので、色々と記録に残すためにレポートを書きます。 私とSRE NEXT SRE NEXTの存在を知ったのはちょうど私がSREを始めて１年経たないくらいの時で、「こんな大きなカンファレンスがあったのか！」と驚きました。 即参加を決めてオンライン視聴しましたが、イベント自体めちゃくちゃ気合いが入っててすげーすげー！言ってました。で、肝心のセッションも弊社の清水さんの発表など非常に胸に刺さるものが多く、特にVTRyoさんの「一人から始めるプロダクトSRE」が今の自分の状況と同じで物凄く感銘を受けたのを覚えています。 youtu.be そこから、「いつかこんな大きな舞台に立てたら嬉しいな〜頑張らないとな〜」と薄っすらですが考えるようになりました。 SRE NEXT 2023開催！ ずっと薄っ

参加した時にメモっていた内容になります。自分向けに投稿。 URL：https://offers.connpass.com/event/290685/ みーんなSREとかQAをチームにしとる チームにしていないのお前だけ - toriさん 開発チームがシステムを運用するオーナーシップ → SRE, QAを安易にチーム化しない → なぜ？ チーム化の理想は？ 専門領域の深掘りを集中的にできる → 果ては他チーム・組織全体にまで波及させる → 希少な人的ソースを基盤化 但し問題がある ・責務分割からの責任の放棄（あっちのチームがいい感じにやってくれるでしょ ・権限問題（あっちの領分だし → 外部からの口出しがしにくくなる → （外部から見て）よくわからんがこうなってる ！！学びの機会の損失！！ 組織の形によっては「こっちで良しなにやりました、あとはよろしく！」となるのが良いのか悪いのかという論争

プロジェクトの依存ライブラリをアップデートする苦行をやっているのですが、その最中で遭遇し解決した事象の話をば。 PostCSSを使っているのですが、その中で postcss-custom-media をv8からv10に上げた時にそれは起きました。 まず、以下のようなPostCSS設定ファイルがあり、 これがv8 -> v9でのbreaking changesにて importFrom が削除されたので、修正する必要がありました。 これについては、以下の内容を参考に postcss-global-data を使う形で解決しました。 github.com 各ComponentにCSSファイルが配置されていて、そこで @custom-media を利用しているのですが、 postcss-global-data を使って別途作成した media-queries.css を読み込ませて解決。 しかし

GKE使っていると定期的にアップグレードの圧がやってきますね。 エイヤッと不用意にクラスタのアップグレードを行うと、deprecatedとなるapiVersionを使ってしまい最悪サービスが不通になる可能性もあります。 本記事ではアップグレード時にいつもやっていることをまとめていますが、暫定のものになるので変遷とともに各々改善していってください。 やっていること まずは上げたいバージョンにアップグレードしても大丈夫かを調査するところから開始します。 確認することは以下の２つ。 上げるバージョンに対して非推奨APIを使っていないかを確認 k8s Change Logを確認 上げるバージョンに対して非推奨APIを使っていないかを確認 Cloud Loggingを使うことで対象バージョンでの非推奨APIを使っていないかどうかをチェックすることができます。 以下のクエリを実行して非推奨APIを使っ

サービスを運用している中で緩やかにメモリ使用率が上がっていく問題があり、それが解決されるまで一時的になんとかするために掲題のを作りました。 github.com 中身自体はZapierが作っていたpreoomkiller-controllerが元になっております。 github.com このコントローラーを導入すれば済む話じゃない？ってなりそうですが、こちらは「メモリ使用量」を閾値としており、更に更新も止まっていたのでせっかくなら勉強がてら作り直すかーとなった結果こうなりました。 この手のk8sに関するツールを今まで全く作ったことがなかったので、勉強に以下の本を読ませていただきました。 実践入門 Kubernetesカスタムコントローラーへの道 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）) 作者:磯 賢大インプレス NextPublishingAmazon pre

たまたま遭遇したけど誤検出のあるあるっぽいなと思ったので調べてメモしとく。 前提としてCloud Armorの事前構成 WAF ルールであるOWASP TOP 10のルールを有効化して運用しておりました。 cloud.google.com 運用自体は特に問題なかったのですが、ある日GraphQLの機能実装をしていたメンバーから特定のリクエストが403で弾かれますと報告を受け調べることに。 Cloud Armorのログを確認する Cloud Loggingで jsonPayload.enforcedSecurityPolicy.outcome="DENY" なログを調べたところ、特定のルールが原因で弾かれていました。 それが、 lfi-v33-stable の owasp-crs-v030301-id930120-lfi で弾かれていて、どうやら .profile がヒットしている様子。 た

必要に迫られて掲題のように「第２・４週の水曜日に動く」GitHub Actionsを作らなくてはいかん状況になったものの、ちと手間だったのでメモ。 GitHub Actionsにはschedule triggerがあり、cron式を書くことによって定期的に動作するActionは作成できます。 ただ、これだと毎週水曜日に動くのでここから隔週にしたいです。 しかしながら、schedule triggerだと隔週にするような方法がないため、steps内で第２・４週かどうかをチェックしていきましょう。 こんな感じになりますかね。もしかしたら同じことを実現するworkflowがMarketplaceにあったりするかもしれないけども動いてるのでヨシ！