「ホットペッパービューティー」美容クリニックでのSRE活動
美容クリニックは新規体制用の少人数体制で開発を行っており、その内の約 7 割がアプリ開発をしているエンジニアとなっています。 一方で、SRE は全体の約 1 割の人数しかいないという状況にあります。 この SRE の人数が少ないかどうかは扱っているシステムの規模や課題によって評価が変わるかと思いますが、美容クリニックが現在抱えている課題の量に対しては少ない人数だと感じています。 では、このように限られた人数の中でどのようにして SRE 活動を行ってきたのかを紹介していきます。 SRE チームの組閣 美容クリニックのリリース以前から SRE チームは存在していたのですが、リリース前後でその責務は変わってきます。 例えばリリース前はインフラの初期構築がメインの責務となってきますが、リリース後（エンハンス開発）にはインフラの保守運用がメインの責務となります。 さらに、メンバーの変動などにより当初
SRE チームをよりサステナブルにするために Vision/Mission/Values を作った話 - スタディサプリ Product Team Blog
小中高 SRE チームで Engineering Manager をやっている @yuya-takeyama です。 Quipper にはスタディサプリ ENGLISH の SRE である ENGLISH SRE チームと合わせて 2 つの SRE チームがありますが、この記事では自分たち小中高 SRE チームについての話です。 少し前の話になるんですが、小中高 SRE チームの Vision, Mission, Values というものをチームで作りました。 Quipper には会社としての Vision, Mission そして Quipper Identities というものがあります。 これらは策定から数年以上経っていますが、Quipper の社員にとって今も変わらず大事なものです。 が、SRE チームにとっては教育や学習に対して直接的に貢献しているとは言いづらい状況です。 そこで
「6社合同 SRE勉強会」で学んだこと
以下イベントを見てたときのメモ的なあれです。SREの初学者目線で学べたことを書きました。全ては見れてません。 全体通して学んだこと 「SREとは」といったところから定義しているところが多かった こうしないとインフラエンジニアの名称が変わっただけのただの便利屋になってしまう 何ができて何をするのか https://blog.studysapuri.jp/entry/sre-vision-mission-values SREはSREでも種類があったりした CenterOfPractice(CoreSRE、pureSRE、横断SREなど) 全社としてのSRE ベストプラクティスの策定 ツールの選定や開発 EmbeddedSRE プロダクト開発チーム内としてのSRE Embeddedだと外から埋め込むという意味合いになってしまうので、内部からの場合はenablingといった表現をしている会社もあっ
コードレビューでコメントタグを使い、心理的安全性を担保しよう
こんにちは。リンクウェル対面診療システムチーム、テックリードの山本です。 今回はコードレビュー時に開発部で実施しているコメントタグのご紹介です。 多分イケてる開発チームではすでに取り組んでいる試みだとは思いつつも、今回はなぜ必要なのかを改めて考えてみたいと思います。 GitHubのプルリクレビューについて 弊社のコードレビューではまず第一に「要求を満たすよう動くこと」が重視されます。その上で次のような点に注視しながら指摘を行います。 外部サービスの特殊な挙動やセキュリティ機構などが考慮されているか。 不具合が発生した時に検知できるようになっているか。 将来的に修正しづらくなる構造になっていないか。 N+1問題などパフォーマンスに問題がないか。 その上でコメントを書く際に次のようにタグを付けて分類しています。 must: 絶対に直して欲しいとき。強い指摘になるので言葉遣いに気をつけるべき i
イラストで理解するIAMロール
はじめに 先日、AWSのアクセス制御についてのプレゼンを行いました。 その際、ポリシーが増える場合、どのように対応すれば良いですか？という質問を頂きました。 そこで、ポリシーを管理するためのIAMロールの説明がうまくできませんでした。 ポリシーやロールは普段から触ることも多いですが、そのメリットをちゃん理解できていなかったことを自覚しました。 そこで、AWSのIAMロール周りのことを聞かれて「ドキッ」とする、そんな私のような方は是非読んでみて下さい。 概要 この記事ではIAMロールの利点に焦点を当てているので、あまり細かい仕組みの説明はしておりませんので、あしからず。 ポリシー ポリシーってなに？ そもそも、ポリシーってなんでしょう？ ポリシーがあって何がいいんでしょう？ では、まずポリシーがない状況を考えましょう。 ポリシー(権限)が無いと、誰でも、いつでも、なんでも、操作できるという状
テックリードがどんな活動したらよいのか考えて行動してみた話 - ZOZO TECH BLOG
2022年6月に、Androidテックリードになった いわたん です。最近、某モンスターを育てたり図鑑を埋めたりするゲームで社内大会をやったらフルボッコにされて涙目でした。悔しくて最近は不思議な力でクラフトしたり空飛んだりして王国を救うゲームやってます。 今回はAndroidテックリードとして1年間やってみた施策の紹介と、それぞれの成果や反省点を紹介したいと思います。これからテックリードになろうとしている方やテックリードをしている方の参考になったり、こんな施策もいいよというアドバイスをもらえたら幸いです。 ZOZOのテックリードの役割と責任 実施した施策 テックリード1on1 読書会 歴史的経緯があるアプリのアーキテクチャ整理へのアプローチ ネーミングセンスを鍛える会の取り組み 案件への関わり方 横断的なコードレビュー 横断的に使う機能の実装 まとめ 最後に ZOZOのテックリードの役割と
配慮のできないエンジニアとの付き合い方 - Qiita
リモートワーク中ワイ ワイ「あーーー！！！」 ワイ「ストレスが溜まるんじゃ〜〜〜！！！」 ワイ「株式会社ゆめみで働くのは、ストレスが溜まるんじゃ〜〜〜！！！」 娘（7歳）「パパ、どうしたの？」 ワイ「いや、あのな？」 ワイ「パパの会社には、エンジニアが沢山おんねん」 娘「知ってるよ」 娘「社員の大半がエンジニアだもんね」 娘「200人以上いるよね」 ワイ「せやねん」 ワイ「そんで、エンジニアってのは、性格にクセのある奴が多いねん」 娘「へ〜」 娘「それで、何がストレスなの？」 ワイ「あのな？」 ズバズバ物を言うエンジニア ワイ「周囲への配慮をせずに、ズバズバ物を言う奴がおんねん」 ワイ「何人もおんねん」 ワイ「それで、周りの人たちは傷ついてると思うねん」 娘「なるほどね」 ワイ「そういうズバズバな奴らがムカつくねん」 ワイ「けしからんねん」 娘「でも、パパも昔はそんな感じだったよね」 娘「
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント - エムスリーテックブログ
【SREチーム ブログリレー4回目】 こんにちは、SREチームの後藤です。 障害が発生した時、魔法のように原因を特定し颯爽と解決していくスーパーな同僚は皆様の周りにもいませんか? その姿に憧れてそうなりたいと思ったことが誰しも一度はあるはず。 ですが、話を聞いてみると「なんとなく怪しそうだった」「勘でここかなと思った」と言われたりして、まったく参考にならなかったこともあるのではないでしょうか。 そこで今回は私が考える障害調査において意識すべきポイントを、なんとなくではなくしっかりと言語化してまとめたいと思います。 題して「なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント」 神頼みしたくなる時も挫けずに強い心を持つことも大事 1. 調査できるように備えておく 2. 事象を正確に把握する 3. 事実と推測を区別する 4. 先入観を排除する 5. 問題を局所化する まとめ
New Relic Syntheticsのスクリプト監視でAPIテストを行う | iret.media
スクリプト監視とは NewRelic Syntheticsには、WebサイトやAPIの監視を行うために、それぞれに適したタイプがあります。 スクリプト監視は、その一部であり、APIエンドポイントを監視するためのカスタムスクリプトを作成する機能です。 主な機能 大まかに以下の機能が使用できます。 – JavaScriptを使用してカスタムスクリプトを作成できる – テストスクリプト内で、HTTPリクエストやデータの抽出などの一般的な操作が実行可能 – 任意のHTTPメソッド（GET、POST、PUTなど）を使用して、APIエンドポイントをテストできる – テストのアサーションを行うことで、特定の条件や期待値が満たされているかどうかを確認することができる 使用例 Syntheticsの作成 Syntheticsの作成はTrraformで行います。 スクリプトは長いので、file( )関数を使っ
SonarCloudと始める静的コード解析 〜ソフトウェア品質向上のための第一歩〜 - ZOZO TECH BLOG
はじめに こんにちは。FAANSバックエンドエンジニアの浜口（@xlgorbylx）です。普段はFAANSのバックエンドシステムの開発をしています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗のショップスタッフの販売サポートツールです。例えば、ZOZOTOWN上で実店舗の在庫取り置きができる機能や、コーディネート投稿の機能などを備えています。投稿されたコーディネートはZOZOTOWNやWEAR、Yahoo!ショッピング、ブランド様のECサイト等に連携が可能です。これによりお客様のコーディネート選びをサポートし、購買体験をより充実したものにします。機能の詳細に関しましては、下記プレスリリースをご覧ください。 corp.zozo.com 本稿では、Go言語で実装されたFAANSのバックエンドシステムについて、SonarSource社の提供するSaaSである「Sonar
「テクニカルプログラムマネージャーはオーケストラの指揮者」 メンバーの多様性を活かし、良いハーモニーを作るTPMの難しさとやりがい
プロジェクトがうまく進まない・何からスタートしていいのかがわからない…TPMが求められる場面 横道稔氏（以下、横道）：入社した時から「このプロダクトです」と決まって入るというよりは、それぞれの組織から依頼があって、プロダクトやプロジェクトに入るというやり方をしていると思います。 なので、そこの依頼の期待値によって、やはり役割が変わってくるんだろうなと思うのですが、どういうプロジェクトが多いんですか？ 大井さん、いかがですか？ なんかちょっと言いにくいなとかがあるかもしれませんが（笑）。 大井宏友氏（以下、大井）：やはりものすごくたくさんの人がサービスに関わっている、あるいはグローバルでさまざまな人たちと1つのプロダクトを作っているので、進め方や文化の違いなど、いろいろな理由でうまく進まない状態に陥っている時がけっこうあるんですよね。そういった時にリクエストが来ることがわりと多いと思います。
「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
第三者的な立場を活かして“組織間のコミュニケーション改善”を担う組織 LINEがテクニカルプログラムマネージャーを専門組織化している理由
綿密なコミュニケーションとリーダーシップで、役割の異なるメンバーを集め仕事を進める、テクニカルプログラムマネージャー（TPM）。LINE社のTPM2名が、その役割や難しさ、やりがいについて話しました。全2回。前半は、LINEにおけるTPMの定義と、テクニカルPM室、Effective Team and Delivery室の役割について。 欧米テック企業にも見られる職種、テクニカルプログラムマネージャー（TPM） 横道稔氏（以下、横道）：テクニカルプログラムマネージャーという仕事について、ご存じの方も初めて聞いた方もいろいろいらっしゃるかなと思うので、前段の知識を簡単に私からお話しします。 TPM（テクニカルプログラムマネージャー）ですが、世の中にある定義を少しだけ引用させてもらっています。これは「Indeed」ですね。海外で求人を出しているIndeedはさまざまな職種の定義を記事にしている
評価エラーを導く要素と対策 | DevelopersIO
ハロー効果は対象を評価する際に目立った特徴を元に関連のない他の項目にその評価を割当ててしまうようなバイアスです。
DX推進のコツは、社員を“3つのタイプ”に分けて役割分担すること DXを成功へと導く、ガンダムにちなんだ「人材」活用法
「世の中を変えるファシリテーターである」というミッションを掲げ、特定の業界・領域に特化せず、さまざまな企業でコンサルティングを行うケンブリッジ・テクノロジー・パートナーズ株式会社。そんな同社の代表取締役社長である榊巻亮氏が、DXプロジェクトを成功させるカギを明かします。本記事では、DXを実現させるためのキーマンとなる「人材」の特徴や、そんな人材を発掘・育成するためのポイントについて語りました。 いわゆる“エリート”は、ビジョンを描くのには不向き？ 榊巻亮氏：（DX案件のポイントの）1つ目で、「『スペースコロニーで人類を生活させたい』みたいなビジョンを描くのが大事。ここがないと本当に道に迷うので、描いてください」という話をしました。 続いて2つ目。じゃあビジョンを作るのは誰なのよ？ と、そろそろ「人」の話に入っていきます。私はガンダムが好きなので、よくガンダムに例えちゃうんですが、イメージは
Amazon ECS の Blue/Green デプロイメントの動作は何が起こっているか解説したい - Qiita
はじめに Amazon ECS は、コンテナを動かしうまく管理するためのコンテナオーケストレーションサービスです。新たなバージョンのコンテナをデプロイするときに、いろいろなデプロイの方法が取れますが、ECS 側で用意されているデプロイ戦略が3種類あります Rolling Update : Service の中で稼働しているタスクを少しずつ順繰りアップデートする方式 Blue/Green Deployment : 新たな環境である Green 環境を用意して、LB レイヤーで切り替える方式 External Deployment : 外部のサードパーティの何かでデプロイをコントロールする方式 こちらの Document に記載があります。 : https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-types.htm
良かれと思ってやったのに…元Google人事が説く、日本の管理職がやりがちなエンジニアの心理的安全性を下げるNG行動四つ - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype 働き方 良かれと思ってやったのに…元Google人事が説く、日本の管理職がやりがちなエンジニアの心理的安全性を下げるNG行動四つ 2023.05.12 働き方 GoogleCEOチーム ここ数年で「心理的安全性」という言葉の認知が広がっている。 特に、人材不足が課題となっているIT業界においては、エンジニアのエンゲージメントを高めたり、離職率を下げたりするために心理的安全性の高い職場づくりに取り組むマネジャーも多いのではないだろうか。 しかし、「心理的安全性の高い組織」を、「対立のない組織」「チームみんなの仲が良い組織」だと考えているとしたら、認識のアップデートが必要だ。 「エンジニアが意欲的に働ける組織とは、何に対しても『いいね、いいね』と肯定することを良しとする『Nice』なチームではなく、時には否定することも恐れず、率直な意見のやり
アジャイルなSREチームの運用
LAPRAS株式会社でSREをしているyktakaha4と申します🐧 弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います 大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください 経緯 弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、 エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました 以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です 原則として、ロールは誰であっても自由に負うことができるので、主務
拡張機能 Git Graph について - Take It Easy!!
やっぱり目で見えると便利 Gitのブランチ構成がグラフィカルに見えるとやっぱり見やすいですよね。 ということで、Git Graph marketplace.visualstudio.com Visual Studio Codeのコードをローカルに持ってきてGit Graph表示してみました。 コード取得します。 c:\work> git clone https://github.com/microsoft/vscode.git Cloning into 'vscode'... remote: Enumerating objects: 14, done. remote: Counting objects: 100% (14/14), done. remote: Compressing objects: 100% (12/12), done. remote: Total 988237 (del
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
