こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo の CI にtfmigrate を導入した話を紹介します。 なお、弊社の Terraform Monorepo に関しては過去の記事も参照してください。 Terraform リポジトリをマージして CI/CD を改善した話 - スタディサプリ Product Team Blog Pull Request の terraform plan の実行結果を S3 に保存して安全に apply - スタディサプリ Product Team Blog Terraform の CI/CD を CodeBuild に移行した話 - スタディサプリ Product Team Blog tfmigrate とは tfmigrate とはなにかについては、 tfmigrate の作者様がこちらの記事で詳し

こんにちは。SRE の @int128 です。 Quipper の SRE チームでは、Platform の安定運用や改善だけでなく、Platform を利用する Developer のサポートも重要な仕事と位置付けています。 SRE チームで工夫していることを紹介します。 Issue に記録を残す SRE チームでは課題や疑問などを気軽に相談してほしいと考えています。 そのため、Slack で気軽に SRE にメンションしてもらえる文化を作るように心がけています。 Slack で相談している例 一方で、同時に多くのメンションを受け取った場合、経緯の把握に時間がかかる、対応状況が分からなくなるといった課題があります。 例えば、Slack のやり取りを通して、ちょっと設定変更すればできるかも、検証してみようという話になることがよくあります。 Slack のスレッドだけでは、具体的な検証作業に

こんにちは。Engineering Manager の @wozaki です。 2年前のプロジェクトで、プレモーテム(premortem)を実施した例をご紹介します。 プレモーテムとは、プロジェクト初期にチームで集まり「プロジェクトが失敗したとして、その失敗とは? 原因は? どう対策するか?」を話し合うワークショップです。*1 プレモーテム実施例 なお、本記事におけるリスクの定義はこちらです。 引用元 熊とワルツを - リスクを愉しむプロジェクト管理 将来起こりうる出来事で、望まない結果を生むもの 望まない結果そのもの 目次 概要 背景 なぜプレモーテムが打ち手だったのか プレモーテムの再設計 実施結果 参加者の所感 最終的にプロジェクトはどうなった? 終わりに 概要 プロジェクトは2つの特性があった 初めて協業するステークホルダーが多い 開発規模が大きい 特性に対する懸念の打ち手としてプ

こんにちは。 Web Engineer の a2ikm です。 先日、 GitHub Actions で失敗したテストをコメントで通知をしてくれる quipper/comment-failure-action という Action を作成し、公開しました。 今回はこの Action を作成するに至った経緯と使い方、そして Action 作成に関する Tips を紹介します。 なぜこの Action を作ったのか スタディサプリは生徒向けサービス、教師向けサービスなどの複数のサービスから構成されていて、それらはひとつのリポジトリに集約して管理されています。 いわゆる monorepo というパターンで、リポジトリ名もそのまま monorepo です。 この monorepo に差分が push されると、 CircleCI と GitHub Actions でサービスごとのテストとデプロイが

こんにちは。SRE の @chaspy です。 Quipper の SRE Team ではじめて「オンボーディング」と呼ばれるものを行って約2年経ちました。 quipper.hatenablog.com その後、3人の仲間が入社し、そのたびにオンボーディングプロセスを改善してきました。 本記事では、SRE Team のオンボーディングプロセスの"いま"を振り返るとともに、その効果や意義を、オンボーディングを受けたメンバーからのコメントを交えて紹介したいと思います。 オンボーディングの目的 あらためてオンボーディングの目的について言語化しておきます。これは今も昔も変わっておらず、「New Joiner の早期の戦力化」だと思っています。 早期の戦力化のためには何が必要か、ということを考えると、現在のチームのミッションから普段の業務へブレークダウンし、それらをスムーズに遂行するために何が必要か

こんにちは。 今回は差し込みの多いプロダクト開発におけるスケジュール精度の上げ方として、バーンアップチャートの利用をおすすめしたいと思います。 どんな人に読んでほしいか Product GrowthやEnhancementに携わっているけど、やることが多くて思ったように進捗が管理できない人 ↑のようなProduct Manager(PdM)やProject Manager(PjM)とのコミュニケーションが多いけど、期待に対してうまく動いてくれないことをもどかしく思ってる方 TL;DR 3ヶ月や6ヶ月程度でタイムボックスを切りましょう タイムボックスの中でやりたいことを全部リストアップして見積もりをしましょう 終わったタスクのcloseと新規タスクのリストアップを繰り返すと、自然と「やりたいことが全部できるのかどうか」が見える化します バーンアップチャートとは 下記のようなものです。 図中の

こんにちは。SREの近藤（@chaspy）です。 新しいサービス、あるいは Microservices を 本番環境へリリースする際、私たちは何を注意すべきでしょうか。 今回は、Production Readiness CheckList と導入方法について説明します。 Production-Readiness Checklist とは Service を本番環境へリリースする前の、信頼性観点でのチェックリストです。このチェックリストを事前に行うことによって、本番での Service 運用開始後の問題をなるべく引き起こさないようにする、あるいは起きたときに最善な手が打てることが期待できます。 Production-Ready Microservices (日本語版：プロダクションレディマイクロサービス ――運用に強い本番対応システムの実装と標準化 を読まれたひとも多いと思います。本書の付録

こんにちは。SRE の @chaspy です。 以前、Production Readiness Checklist に関する記事を書きました。 quipper.hatenablog.com Production Readiness Checklist の運用開始から1年ほどの月日が経ち、27ものサービスが無事 Production へ出ていきました。 サービスを安心して Production へリリースするために役立っている Production Readiness Checklist ですが、Product Team がこの Check List を進める上でいくつか課題がありました。 本記事では、Production Readiness Checklist 運用開始後に、どのような改善が行われてきたのか、その内容と方法を説明します。また、1年以上の運用を通して、Production R

こんにちは、2019年10月からQuipperにjoinした @qsona です。ということはつい数ヶ月前までは一採用候補者としてQuipperの採用を受けていたことになりますが、その中で、Quipperの採用には良い特色が多くあると感じました。今後はQuipperの一員として採用する側に回ることになりますが、採用候補者の視点から感じたことを忘れないうちにこの記事に書きたいと思います。(この記事の9割は入社前に書き上げていたのですが、入社後は普通に仕事が面白すぎて記事を放置してしまい、4ヶ月も経ってしまいました。こうならないように、書いたらさっさと出すのが鉄則です!) 概要 Quipperの面接のフローや各ステップの目的は、ガイドにまとめられています。以下はWebエンジニアの面接ガイドです。 Quipper Web Engineer 東京オフィス採用面接ガイド また、ここに書かれている以外

こんにちは。SRE の近藤（@chaspy）です。 先日、より高い信頼性でサービスを提供するために、スタディサプリ小中高大のサービスの最後の砦であるデータベース、MongoDB のインスタンスクラスのスケールアップを行いました。また、スケールアップをするにあたり、負荷試験を行いました。 本記事では、データベースインスタンスのスケールアップの際に行なった負荷試験に対する考え方と、得た学びを紹介します。 なぜスケールアップするのか サービスの急成長に伴い、アクセス数もデータ量も増加しています。数年前に「しばらくは大丈夫」と判断できるインスタンスクラスにスケールアップをしたデータベースも、高負荷時には性能が劣化してしまう問題に遭遇しました。 私たちの MongoDB は AWS 上に EC2 インスタンスとしてセルフホストしており、MongoDB Cloud Manager を使って運用の一部を

Quipper Product Blog守り手の@chiiia12です。 ちょうど今日5/28でQuipper Product Blogを再開して1年が経ちました。この機会に再開してからの1年間を振り返り、ブログをどう運用してきたかについてご紹介したいと思います。 Quipper Product Blogの再開 Quipperではメンバーが書くブログ自体は以前から存在しましたが、更新が滞っておりほぼ運用されていない状態でした。長期的な採用ブランディングのためにも1年前の今日、Quipper Product Blogを再開することになりました。 quipper.hatenablog.com 再開してからは、週に1記事を目標に1年間走り続けて来ました。ブログの継続的な記事公開を促す役割である "守り手" もhotchemiさんから受け継ぎ、運用を続けています。 ブログでの継続的なアウトプットの