大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
[t_wada氏×カミナシTori氏]ソフトウェアエンジニアと品質保証 SRE、QAの枠にとらわれない新しい視点 | Offers Magazine
前提として、カミナシが目指しているエンジニアリング組織の形について、CTOとして以下の三つの原則をブログ記事で明示しました。 すべてはオーナーシップ 開発チーム自身がシステムを運用する SRE、QA、プラットフォームの類を安易にチーム化しない この三つの原則は、価値ある製品を顧客に届けるためには開発チーム自身のオーナーシップが不可欠であり、そのためには各チームが自らのシステムを運用する重要性、そしてSREやQAなどを単独のチームに分けないことを示しています。 チーム化の理想としては、以下の三点が挙げられます。 フォーカスによる専門領域のExecution Level 深化 チームごとの役割分担による組織全体のExecution Level 深化 希少な人的リソースの「基盤」化 各個人が専門領域にフォーカスすることでExecution Levelを高め、チームが役割を分担することで組織全体の
![[t_wada氏×カミナシTori氏]ソフトウェアエンジニアと品質保証 SRE、QAの枠にとらわれない新しい視点 | Offers Magazine](https://cdn-ak-scissors.b.st-hatena.com/image/square/22d449c58c1eb5d9e28ee9350a10c50da3956732/height=288;version=1;width=512/https%3A%2F%2Fs3-ap-northeast-1.amazonaws.com%2Fassets.offers.jp%2Fmedia%2Fwp-content%2Fuploads%2F2023%2F12%2F27105156%2Freport_quality_assurance.png)
多様なプロダクトが存在する freee における health check 標準化 - freee Developers Hub
こんにちは。freee の Platform Solution チーム1 に所属している nkgw （Twitter） です。 この記事は freee 基盤チーム Advent Calendar 2023 の 15 日目の記事となります。 普段は、エンジニアリングマネージャーをしつつ、新規プロダクトのリリースサポートとか、プロダクトのキャパシティプランニングやコンピューティングリソース調整などをやってました。 今回、freee のプロダクトにおける health check の標準化について取り組みました。health check の要件と非標準化がもたらす具体的な問題を整理しつつ、freee では実際にはどのように health check を定義したのかを紹介します。 その前に... 詳細な内容の前に、弊社のような複数のプロダクトが相互に依存関係があるような環境下における health
クラシルのSREをチーム化するときに意識した3つのことと半年間の実績 - dely Tech Blog
こちらは、「dely Advent Calendar 2021」21日目の記事です。 昨日は、PdM櫻本さんの「とりあえずやってみる。精神について」という記事でした。 何か新しいことにチャレンジしてみたいと思っている方は、ぜひ読んでみてください！ はじめに こんにちは、クラシル開発部SREチームの松嶋です。 今年の10月に「SREがプロダクトの価値を最大化するためにチームとして取り組んできたこと」と題して、私たちが足元課題解決型の体制から脱却し、チームとして効果的に機能するために取り組んできたことについて5つ紹介しました。 tech.dely.jp こちらの記事で紹介している取り組みは、クラシルというプロダクトの成長を加速させていくために私たちは何をすべきなのか議論し、必要なことを地道に取り組んできただけなので、「これをやれば上手くいく！」というような銀の弾丸になるアクションは特にありませ
AWSの開発環境の利用時間をGoogleカレンダー連動させたら開発チームが自由に使えてコスト70%削減！！ - Uzabase for Engineers
こんにちはNewsPicks SREチームの美濃部です。 NewsPicksのSREのミッションの1つに「コストを適正化する」というものがあります。サービスの規模拡大に比例してインフラコストが増えないようにし、売上に対するコストの割合を低く維持していくのがミッションになります。 今回はこのミッションに対するアクションとして開発環境のインフラコストを適正化した話をします。 NewsPicksの開発環境について 開発環境のコストをどうやって適正化したか 稼働時間対応を実現する仕組みについて 実際どれくらい削減できたのか まとめ NewsPicksの開発環境について まず、NewsPicksの開発環境について概要を説明します。 インフラ基盤は本番環境と同様にAWSを利用しており開発チームは現在10以上のチームが存在し、それぞれのチーム専用に用意された開発環境を利用しています。 2年程前までは開発
Zero Touch Productionへの移行 | メルカリエンジニアリング
※本記事は2022年1月26日に公開された記事の翻訳版です。 筆者：Dylan Lau (@aidiruu), Platform DXチーム Zero Touch Production (ZTP)は、本番環境に加えられるすべての変更が、自動化、安全なプロキシ、または監査可能なBreak-glass（緊急アクセス）システムによっておこなわれるという概念です。人為的ミスに起因する本番環境での障害には、次のようなさまざまな種類があります。 構成エラー スクリプトエラー 間違った環境でのコマンド実行 ZTPはこれらのエラーによる障害発生のリスクを軽減できます。メルカリでは、ZTP環境への移行に取り組んでいます。最初のステップは、一時的な役割付与システムであるCarrierを実装することです。 この記事では、以下について説明します。 ZTPの重要性 ZTPを実装するプロセスとCarrierを始めた理
【書き起こし】Kubernetesの上に作る、統一されたマイクロサービス運用体験 – tkuchiki【Merpay Tech Fest 2022】 | メルカリエンジニアリング
【書き起こし】Kubernetesの上に作る、統一されたマイクロサービス運用体験 – tkuchiki【Merpay Tech Fest 2022】 Merpay Tech Fest 2022 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2022年8月23日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。 この記事は、「Kubernetesの上に作る、統一されたマイクロサービス運用体験」の書き起こしです。 「Kubernetesの上に作る、統一されたマイクロサービス運用体験」というタイトルで発表します。よろしくお願いいたします。 まずは自己紹介です。メルペイSREチームのtkuchikiと申します。 Cloud Spanner周りの業務に従事
2022: freee SRE Journey - これまでの振り返りとこれから - freee Developers Hub
忙しい方向けサマリ EKS化・IaCの浸透・DB改善活動が、ここ数年のfreeeのインフラ事情の主だった動きです。 一方で組織・サービスも増えてきており、従来のワンチームSREでは色々と厳しくなってきました。 基盤も進化し、課題も変化した。それに伴い、SREの組織構造を、チームトポロジ的に再編しました。 本文 こんにちは、freeeでSREのマネージャをやっている河村です。 freeeは会計年度の開始月が7月となっており一つの節目となっています。加えて今年はfreee創業10周年ということで、一つのマイルストーンとして、freeeのSREの現状と、それを受けた今後の展望について整理してみました。 この数年の中で、EKS化やAurora化といった基盤の刷新が進む一方、プロダクト・組織規模拡大に伴う従来型SREチームのスケール限界が顕在化してきています。それに対し、新しい基盤に合わせた仕組みの
PairsにおけるSLI/SLO再定義
https://sre-lounge.connpass.com/event/227250/
Misocaのサービスレベル目標 (SLO) を設定するまでの道のり - 弥生開発者ブログ
Misoca開発メンバー/SREチームの id:mizukmb です。今年も最高気温40度超えの名古屋の夏を乗り切る事ができて安心しています。 今回はSREチームとしてMisocaのパフォーマンス計測を行い、開発向けのサービスレベル目標 (以下、SLO) を設定した話をしようと思います。 実際に計測をはじめる前に すべてを計測できることは理想ではありますが、闇雲に計測するだけではどこを改善するべきか見えにくくなってしまいます。 そこで、実際に計測をはじめる前にSREとしてどこに着目するべきなのかをSREチーム内で認識合わせをするためにSRE本読書会を実施しました。 SRE本読書会の実施 SRE本とは SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム の事です。 Google - Site Reliability Engineering で
Zero Touch Productionとは何か
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least
継続的なソフトウェア・アップデートのためのDevOpsベストプラクティス・アンチパターン / DevOps Patterns and Antipatterns for Continuous Software Updates
Cloud Native Days Tokyo 2020
「マンガが快適に読める」を数値化し、SLOをマンガビューワに導入するまで - Hatena Developer Blog
マンガビューワにおけるサービスレベルとは なぜSLOを策定したかったのか サービスレベルを単純に決める 何をサービスレベル指標としてどう計測するか 一般的なSLIの表現 期間を移動しながら集計する アクセスログからサーバーのSLIを計測する PageSpeed Insights APIでフロントエンドを計測 プロダクトオーナーとともにSLOを決定する 決定したSLO どのように監視するか まとめ 株式会社はてなのマンガチームでSREをしているhappy_siroです。 私がチームで担当しているサービスは、いくつかのWebマンガサイトで採用されている「GigaViewer」というマンガビューワです。 GigaViewerチームでは、サービスのSLOを策定しました。 理由は、SLOに基づいて開発速度と信頼性のバランスをとるためです。 この記事では、私がチームメンバーと協力して「GigaView
Chapter 12 - Introducing Non-Abstract Large System Design, Google SRE Book
Introducing Non-Abstract Large System Design By Salim Virji, James Youngman, Henry Robertson, Stephen Thorne, Dave Rensin, and Zoltan Egyed with Richard Bondi With responsibilities that span production operations and product engineering, SRE is in a unique position to align business case requirements and operational costs. Product engineering teams may not be aware of the maintenance cost of syste
「ZOZO MLOps のチームリーディングとSRE(Engineering)」というタイトルで SRE Next 2020 に登壇しました
1/25(土) に開催された「SRE Next 2020」 という日本では初めて行われる SRE (Site Reliability Engineering) に関するカンファレンスに登壇しました。 2019年4月にチームを新規に発足してから、どのようにチームを率いて成果を上げ、社内の信頼を得てきたのか 、メンバーの成長を促してきたのか、について語りました。 https://docs.google.com/presentation/d/1zEkR9Dm_epg7fxOCFE-asBsUlHDozwObsBEGAILiqic/edit#slide=id.p1 [B6] ZOZO MLOps のチームリーディングとSRE(Engineering) 私は2019年4月にZOZOにMLOpsチームを作り、それから10ヶ月ほどチームをリードしてきました。 その10ヶ月の間にZOZOでは買収も含め色々
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 - エンジニアHub｜Webエンジニアのキャリアを考える！
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 SREの役割には、信頼性、SLIとSLO、エラーバジェット、トイル、ソフトウェアエンジニアリングといった複数のキーワードが存在するがゆえ、なかなかうまく実践できない、という声もあります。本稿では、難しく見られがちなSREの内実を、「信頼性の制御」というコンセプトを軸に整理し、小さく始める一歩を坪内佑樹（ゆううき）さんが解説します。 こんにちは。SREの研究者をやっているゆううき（@yuuk1t）です。 SRE（Site Reliability Engineering）は、従来のオペレーションエンジニア、システム管理者（sysadmin）と呼ばれる人々が担っていた技術領域の新しい形です。Googleによって提唱され、日本国内でも2015年ごろからWebコンテンツ事業者のコミュニティを中心に広く知られる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SRE不在のチームに入って2ヶ月でやったこと - 負荷試験ツールからはじめるSREプラクティスの導入
ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist
監視論 ～SREと次世代MSP～
ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)