こんにちは。SREのkyontanです。Rubyが大好きなのでRubyの話をします。ちなみにリクルートはRubyKaigi 2024へGold Sponsorとして協賛しています! *1。ぜひ沖縄でお会いしましょう。 これはあるアプリケーションのメモリ消費量を示すグラフなのですが、まさかgemを入れ替えるだけでこんなに嬉しい変化が見られるとは思っていませんでした。今日はそんなgemの話をします。 話は遡って2023年4月のある日、インターネットを眺めていたところ、ShopifyがpitchforkというOSSを公開したという情報が目に留まりました。 調べてみると、どうやら著名なRackサーバー実装の1つであるunicornの派生版であり、メモリ使用量の削減に特化しているらしいのです。 github.com これはスタディサプリ小中高のあのリソースドカ食いマイクロサービス第一位である api

ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で

はじめまして、Web Developerの@tricknotesです。 今回はチームの期待を合わせるためのワークショップである「ドラッカー風エクササイズ」をわたしたちのチームで実践してみました、というお話です。 背景 なんでこのワークショップをやってみようと思ったのか…という話をする前に、まずわたしたちのチームの状況をお伝えさせてください。 わたしたちのチームは、ここ半年ほどで多くのメンバーが増えました。 その結果、古くからのドメイン知識に明るい古株層とまだまだドメイン知識の吸収を必要としている新入りメンバー層の間で大きな知識の隔たりがあるという状況になっています。*1 そんな中、歴史的経緯は気にせずいまの開発に集中してほしい古株メンバーと、そういった歴史的経緯を含めて吸収していきたい新入りメンバーの思いがそれぞれある、ということが振り返りの場で明らかになりました。 どちらもチームのためを

最終更新日: 2024年05月07日(火) 1. ご挨拶 2. 本記事執筆のモチベーション 3. ワークショップを通じて得たフィードバック 3-1. Pains -過去抱えた/現在進行形で抱えている辛み- 3-2. Approaches/Solutions -Pains を解消するために取った方策や導き出した解決策- 3-2-1. えいやで場所を決め打ちしてしまう(e.g., GitHub Wiki + Google docs しか使わない) 3-2-2. 個人的に、2023/12/05時点で〜みたいな書き方を心がけている 3-3. Tips -効果的な手法- 4. オーディエンスからの反響 4-1. 気づきや学び・NEXT ACTIONS 4-2. プレゼンター(@hayat01sh1da)へのフィードバック 4-3. Slack での反応 5. おわりに 1. ご挨拶 初投稿となります

こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI を AWS CodeBuild (以下 CodeBuild) から GitHub Actions + tfaction に移行した話を紹介します。 これまでの Terraform Workflow (CodeBuild) 弊プロダクトの Terraform の CI に関しては過去の記事でも何度か紹介していますが、 元々 CodeBuild 上で CI を実行していました。 かつては CircleCI 上で実行していましたが、 CodeBuild に移行しました。 blog.studysapuri.jp CodeBuild に移行した理由は大きく 2 つありました。 Security 永続的な Access Key を発行することなく AWS のリソースを管理できる GCP に関しても Wor

こんにちは。SREの@kyontanです。スタディサプリのSREチームにジョインしてから初のブログ記事となります。 つい先日、スタディサプリ 中学講座が大幅リニューアルされました。*1 今回は、そのリリースを自信を持ってユーザーの皆様へお届けするために実施した、プレモーテムという取り組みについてご紹介したいと思います。 背景 今回のスタディサプリ 中学講座のリニューアルは、バックエンド、フロントエンド(Web/iOS/Android)の開発をフルスクラッチで行ったため、大規模なリリースとなりました。 すでにユーザーへ提供しているサービスを、段階的にリニューアルされたものへ切り替えていく複雑なリリースということもあり、リリースにあたっては予期しないトラブルが起きる可能性が推測できます。 通常、さまざまなトラブル(障害)が起きた際には、私たちはあらかじめ定めた障害対応フローに沿って対応を行い、

こんにちは。SRE の @chaspy です。 先日行われた SRE NEXT 2020 にて、SLO Review というタイトルで発表してきました。 本記事では、会場に来られた方には内容を追体験してもらえるように、来られなかった方には伝えたかった内容を持ち帰っていただけるように解説します。 来場者への質問 本セッションを聴きに来られている会場の方に、SLO に関する質問をしました。 会場への質問 SLO という言葉の意味を知っているひと：9割以上、ほとんど全員 自分のサービスに SLO を定めて運用をしているひと：2割程度 Error Budget Policy を定めて、SLO 違反になった際にリリースを止めるなどをしているひと：2,3人 事前に予想した通りの比率でした。まさに僕の発表は 1 を満たしているが、2をこれからやる、というひとに対するヒントを提供する発表だったからです。

ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス