社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU
自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。 自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。 前提のスタンス 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい 自分用メモを作る キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい 過去のドキュメント・やりとりを探す 全体像を把握できるドキュメントがないかを探すのを最初にやってる ここは近道はない。とにかく全部集めて全部読む気持ちで臨む Google D
なれる!SRE - Becoming SREで学んだこと - じゃあ、おうちで学べる
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
ポストモーテムを理解する - Qiita
はじめに こんにちは、webエンジニアの@an_sonyです。 最近、障害対応の振り返りをしていた時に「ポストモーテム」という手法を初めて知りました。これまで「どうやったら良い振り返りができるのか？」と悩んでいた自分にとって目から鱗の知識ばかりでしたので、整理のためにまとめてみます。 ポストモーテムとは？ SRE サイトリライアビリティエンジニアリング1によると、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるドキュメントを指します。 言い換えると、失敗（障害）から学び、再発防止策を決める活動です。 障害報告書との違い 障害報告書と内容が似ていますが、ポストモーテムは読者と目的が違います。 障害報告書は、障害発生によって不利益が生じたユーザーに対して、その説明をするため
障害対応で大切だと感じていることのまとめ - Qiita
私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは
コスト最適化目的で個人 AWS アカウントの整理をした
ここしばらく円安が続いているのと、結局自宅サーバのおもりがへたっぴで崩壊し続けている関係で EC2 とかばんばか使っていたら日本円コストが嵩んでしまっていた。2024/2 から Public IPv4 Address 課金も開始されるのもきっかけ。 なんとかすべく 2023 年末に休みを取って大整理をやった。サボっていたけどこのままだとさすがにキツいなと思って基本的にはしょうもない整理です。基本的には homelab として意図的に色々あそべるようにしていたのを止めたりとかになる。ご笑覧ください。 どんなもん 月間コスト 378 USD (2023/8) → 153 USD (2023/12), without tax 日本円コスト 59,099 JPY → 24,583 JPY/mo, with tax 内訳 (USD); EC2-Instances: 140.92 → 61.27 S3
Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
（SRE的）作ってよかったドキュメント・表・運用
これは、SRE Advent Calendar 2023の18日目の記事です はじめに LAPRAS株式会社でSREをしているyktakaha4と申します🐧 私は、LAPRAS株式会社にSWEとして入社後、ロールチェンジを経て約2年間にわたって組織のLead SREとしてプロダクトの改善に取り組んできました 技術面での学びがあったり、うまくいったな～と感じたものについては適宜Zennに記事を書いてきたのですが、ちょっとしたドキュメンテーションでなどの記事にするほどまとまった分量が取れない小ネタ🍣については書くきっかけが無く、環境が変わったり忘れたりして揮発してしまう前に何かしら備忘メモを遺しておきたいと考えていました そんな折に、ちょうどこのアドベントカレンダーのことを知り、よい機会なので参加することとしました🐤 大規模だったり技術難易度の高い組織でバリバリ働かれている方には物足りな
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita
この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の4日目です。年末進行、いかがお過ごしでしょうか？みなさま無事に仕事が納まることを願っております… 新人インフラエンジニアが、本番ウェブサーバー60台のホスト名を全部 cat にしてしまった話について、ここに供養させていただきたいと思います 背景 おそらく今から7年くらい前、インフラエンジニアとして転職してきて1年ほどが経ち、本番環境での作業もこなれてきたなというバッチリのタイミングで事を起こしてしまいました。サーバーは CentOS 6 だったと思います。 職場としてはまだまだベンチャー感にあふれ大きな裁量が与えられスピード感のある環境ながら、サービスの登録ユーザー数は1,000万を超え、本番環境の規模としては既になかなかの大きさがあり、ウェブサーバーだけでも60台くらいあったと思います。ひと山につき
エンジニアは全員おうちKubernetesをやるべし【Part 1：なぜやるのか】 - Qiita
こんにちは。おうちKubernetesを勧めるためにやってきました。 このシリーズでは、Part 1で「なぜやるのか」、Part 2で「どうやるのか」について話します。 この記事は自宅サーバー上のKubernetesで不特定多数向けのサービスを展開することを勧めるものではなく、自分用・身内用のアプリを自宅サーバー上のKubernetesで運用することを勧めるものです。 エンジニアは全員おうちKubernetesをやるべき絶対的な理由 自己研鑽のために （鑽←この字「研鑽」と「大鑽井盆地」でしか見ない） 企業がKubernetesを採用する場合、ほとんどがEKSやGKEといったクラウド上で動作するマネージドKubernetesサービスを使用すると思います。ただ、Kubernetesであればコマンドやマニフェストファイルの書き方は共通なので、おうちKubernetesで学んだことがそのまま業務
ソフトウェアはなぜバージョンアップしなければならないのか - Qiita
はじめに 社内インフラの運用担当者にとってソフトウェアのバージョンアップは地味な割に大変な業務です。 特に社内のオンプレサーバで動いているようなソフトウェアの場合、バージョンアップに伴う諸々の調整をそのソフトウェアを利用している各部署と行う必要があります。 そんなときに「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは？」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。 この文章はそんな時になぜバージョンアップしなければならないのかを上司や各部署のマネージャに伝えるために書きます。 ソフトウェアの有効期限は2-5年 まず、第一に、ソフトウェアというものは無限に使えるわけではなく、一定の有効期限があり、それを過ぎると徐々に動かなくなってきます。俗にいう「何もしてないのに動かなくなった問題」です。 なぜ
カスタマーサポートだけど、開発チームに敬意が持てない
うちの会社のシステム、ほぼ毎日いろんなバグが見つかってお客さんからクレームがきてる。 バグが直った時に、slack上では開発チームに「修正ありがとうございます」って送ってるけど、なんで自分たちが「ありがとうございます」と言っているのかよくわからない。 開発チームが品質の悪いシステムをつくって、 お客さんがバグを見つけて怒って、 カスタマーサポートがお客さんのサンドバッグになって、 開発チームがバグを直して、 カスタマーサポートが開発チームにお礼を言う。 なにかがおかしい。なんだこれ。 自分で引き起こした問題を自分で解消してなぜ感謝される構図になっているんだろうか。ただのマッチポンプじゃないか。 カスタマーサポートはお客さんをサポートするための仕事なんだよ。 不出来な開発チームのための緩衝材じゃないんだよ。 本当はサポートだけじゃなく、サクセスみたいなことも色々やっていきたいと思ってるよ。
障害対応プロセスを改善してきた話 - 10X Product Blog
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
アジャイルなSREチームの運用
LAPRAS株式会社でSREをしているyktakaha4と申します🐧 弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います 大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください 経緯 弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、 エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました 以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です 原則として、ロールは誰であっても自由に負うことができるので、主務
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリングから継続
MySQLパフォーマンスチューニングのためのクエリの基礎知識 - プログラマーkkの勉強/成長ブログ@ライブレボリューション(モバイル広告代理店)
前回書いたMySQLパフォーマンスチューニングのためのインデックスの基礎知識に引き続き、MySQLのパフォーマンスチューニングについて学んだことをまとめ。 MySQLを使っていると、クエリが遅い理由をつきとめる必要が出てくる。 どうやって遅いクエリをつきとめ、改善すればよいかについて学んだのでまとめた。 下記のような基礎知識があればパフォーマンスチューニングをうまくやれる、と思う。 クエリ処理の基礎 MySQLがクエリを処理する手順 まずはMySQLがクエリを処理する手順を知っておく必要がある。 処理は以下のような流れで進む。 クエリキャッシュの中からクエリの結果を探す。見つかればそれを返す。 クエリを解析して構成要素に分解する。 クエリの構文が正しいことを確認 クエリについて基本情報を収集する。 クエリを基本的な要素に分解した後、何を実行すべきかを判断する。 クエリオプティマイザが動き始
文化祭で滞在状況記録システムを運用しました
文化祭からはや 3 ヶ月。ずっと書きたいとは思っていたんですが、すぐ定期試験がやってきたり修学旅行に行ったりしてるうちにズルズル来てしまいました。このまま年を越すわけには行かないので、重い腰を上げて書き上げてしまおうと思います。 文章力が皆無なので読みづらい箇所があったらごめんなさい。質問等ございましたらお気軽にどうぞ！ 1. システム概要 感染症対策の一環として、主に各展示の同時滞在者数の抑制を目的として導入したシステムです。 文化祭への来場者全員にリストバンドを配布します。各リストバンドには個別の QR コードがプリントされており、各展示の入室時及び退室時に、展示のスタッフが Web アプリ上でスキャンを行い、来場者の入退室時間を記録します。 主な機能として以下が挙げられます。 同じ時間に同じ教室にいたのがどのリストバンドをつけていた来場者であるかが分かるため、万が一新型コロナウイルス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クリティカルユーザージャーニーを利用した SLI/SLO の改善 / #mackerelio
Node.js v12 を使い続けていたのはなぁぜなぁぜ？
問い合わせ率が3年間で半分になった
