はてなブックマーク

これは、SRE Advent Calendar 2023の18日目の記事です はじめに LAPRAS株式会社でSREをしているyktakaha4と申します🐧 私は、LAPRAS株式会社にSWEとして入社後、ロールチェンジを経て約2年間にわたって組織のLead SREとしてプロダクトの改善に取り組んできました 技術面での学びがあったり、うまくいったな～と感じたものについては適宜Zennに記事を書いてきたのですが、ちょっとしたドキュメンテーションでなどの記事にするほどまとまった分量が取れない小ネタ🍣については書くきっかけが無く、環境が変わったり忘れたりして揮発してしまう前に何かしら備忘メモを遺しておきたいと考えていました そんな折に、ちょうどこのアドベントカレンダーのことを知り、よい機会なので参加することとしました🐤 大規模だったり技術難易度の高い組織でバリバリ働かれている方には物足りな

ここ半年ぐらいスクラップでまとめていた読書ログが一定の分量になったため、記事にすることにしました 気になっている本はまだまだあるのですが、知識欲としては一旦落ち着いたので区切りを兼ねて記します📝 オススメの本があれば教えてもらえると嬉しいです📖 モチベーション 2010年代からITエンジニアとして働きはじめたため、それ以前にあった出来事や歴史を知らない 最新の技術書やネット記事を読んでも、過去にどんなことがあったか、どんなことが考えられていたかはあまりわからない 名著と呼ばれるものは数多くあるが、どれから読みはじめればより理解が深まるのかわからない 例えば 人月の神話 は、当時に対して一定の事前知識があった方がより楽しめる本だと感じる 当時についての事前知識を持たない一技術者の視点から、それらの本を読んで感じたことをまとめるとよいのでは 興味を持った領域でどの本を最初に読むか比較しなが

LAPRAS株式会社でSREをしているyktakaha4と申します🐧 弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います 大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください 経緯 弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、 エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました 以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です 原則として、ロールは誰であっても自由に負うことができるので、主務

LAPRAS株式会社でSREをしております yktakaha4 と申します 🐧 今回は、仕事のひとつとして1年くらい取り組んでいたEKSクラスタのバージョンアップの運用改善について一息つけたので、振り返りを兼ねて備忘録を遺したいと思います ✍ 先にお断りしておくと、この記事で話すのは 運用ノウハウが{ほぼ無い,失われてしまった}EKSクラスタに対して、手順改善やリファクタリングを通じて継続的なバージョンアップ運用を再開する方法 というあまり胸を張れない内容です ネットの記事やカンファレンスを見ていると、大規模環境や高トラフィック下における取り組みや、初期構築の段階で充分な運用設計を済ませている素晴らしい事例などが目に留まります 一方で、過去に選定したk8sを破棄して元の技術スタックに戻す意思決定をしたプロジェクトについて見かけることもあります 各社においても様々なコンテキストがあるものと

これは、LAPRAS Advent Calendar 2022の8日目の記事（代理投稿）です また、この記事を書き始める前に眺めていたらたまたまいいタイミングで空いていたので、Go Advent Calendar 2022 の22日目にもエントリーしたいと思います なにこれ LAPRAS株式会社でSREをしていますyktakaha4と申します 🐧 このたび、Gitのリポジトリを検索し、コントリビューター毎に今稼働しているSLOCに応じて日本地図を塗り分けして可視化する Kunitori というCLIをGoを使って作りましたので、そのご紹介と学んだことを残したいと思います ✍ Kunitoriで生成した日本地図 作った理由 突然ですが、みなさんの一番好きなGitHubの画面はどこでしょうか 私は /graphs/contributors です 各コントリビューターがリポジトリにどの程度コミ

ふと気になって調べたことの備忘メモです ✍ （2022/11/3追記）ご指摘頂いた内容を踏まえて加筆修正をおこないました なぜ調べたか Webアプリケーションの開発に携わっていると CSRF という脆弱性への対処を求められますが、多くの場合利用しているフレームワークが設定追加だけで対応してくれたり、既に前任者によって適切な処置がされていたりなど、実務上で目を向ける機会はその重要性と比較して少ないのでないかと思います また、Webブラウザの実装やHTTP周辺の関連仕様の変化から陳腐化している情報も多く、現代において全体感と具体的な対処法を理解するには少しばかりハードルが高いように感じていました ですので、自身の現時点での認識を明文化して残しておくことにしました なお、私はWebセキュリティの専門家でなく、一介の開発者のため、誤りが多分に含まれる可能性があります ご指摘を頂ければ修正したいと思

LAPRAS株式会社でSREをしていますyktakaha4と申します 🐧 私は 2021 年の 1 月に LAPRAS に入社 したのですが、 入社以来ほそぼそとやってきた、ドキュメンテーションに関する取り組みについて一年ほど運用し一区切りがついたので、その話をしたいと思います✍ ことのおこり 現在弊社には正社員・業務委託あわせて 18 名程度のエンジニアが在籍 していますが、 私が入社した頃はエンジニアが7名程度、かつ全体の人数に対して在任歴の長い人が多かったこともあり、 開発者が参照するドキュメント管理について、比較的牧歌的な運用がなされていました 🐑 具体的には、開発環境の構築方法が古い手順のまま放置されていたり、オンボーディングに使うドキュメントが口伝されていたりと、 ドキュメント自体は存在するものの、それらが 古くなっていたり一覧化が不十分であることが検知できず、時間経過に伴

LAPRAS株式会社でSREをしております、yktakaha4と申します🐧 最近、LAPRASにポートフォリオをユーザー自身でカスタマイズする機能がリリースされたのですが、 こちらに関連してSREとしてSorryページ（メンテナンスページ）を表示する機能を開発したので、 設計・実装にあたって意識した点などについて書き遺したいと思います✍ ことのおこり 弊社では毎朝エンジニア全員（10数名程度）で集まって朝会を実施しているのですが、 ある日、スクラムチームの naga3 から以下のようなアジェンダが出ました 今回の機能を実装するにあたって、そこそこレコード量が多くユーザー影響の大きいテーブルにカラム追加のマイグレーションをおこなう必要があり、 これについて作業手順上の不安があったので、夜間リリースで対処したい…という議題だったのですが、 そこから マイグレーションの失敗等に伴い本番環境の動

ふと気になって調べたことの備忘メモです ✍ （2022/4/2追記）Twitterやはてブで色々とご指摘やコメントを頂いたので、それに基づいて加筆と修正をおこないました 特に、幾つかの技術については完全に誤った説明をしてしまっており、大変助かりました…ありがとうございました🙏 （2024/8/13追記）今年に入って、実務で使える メール技術の教科書という本が出版されています🎉 私も買って読みましたが、電子メールに関するトピックについて広くカバーされていました パブリッククラウドに関する記述は少な目ですが、メールサーバーを自身で構築する方法が紹介されていたりなど、より基礎的な内容に主眼をおいている本だと思います なぜ調べたか メール送信機能のあるWebアプリケーションを開発・運用していると、 特定のアドレスに対してメールが届かないんだが とか MAILER-DAEMONなるアドレスからメ

LAPRAS株式会社でSREをしていますyktakaha4と申します🐧 みなさんの会社ではSLOやエラーバジェットに関する運用をおこなっていますでしょうか？ おなじみSRE本にも謳われる通り、これらは機能開発とシステムの信頼性維持をコントロールするための非常に優れた方法ですが、 エラーバジェットが枯渇してしまった時に、解決に向けてプロダクトチームやSREがどのように振る舞うべきか については踏み込んで言及されておらず、組織の形態にあわせてよりよい適用方法を模索する必要があるものと思います 今回は、（残念ながら😿）弊社で実際に発生した エラーバジェット枯渇と、それに伴う本番環境への機能フリーズ事例 をご紹介します 自社サービス開発をおこなっている組織におけるモデルケース のひとつとして参考になる部分があれば幸いです🚙 フリーズから解除に至るまで ことのおこり 弊社では、エンジニア向けポ

LAPRAS株式会社でエンジニアをしてます@yktakaha4ともうします🐠 この記事は、LAPRAS Advent Calendar 2021 2日目の記事です 先日、GitHub ActionsがOIDCに対応しましたが、ネットを探すとベータとして公開されていた時期の情報が残っていて若干動かしづらい部分があったため、備忘メモとして残すこととしました✍ なににアクセスするかについては丁度いいネタが思いつかなかったので、 直近でTerraformでサッと使える検証用EKS環境を作ったという記事を書いていたため、 この時作ったEKSクラスタにGitHub Actionsからアクセスし、マニフェストを適用するワークフローを書いてみました KubernetesのデプロイについてはGitOpsでおこなっている方も多いかもしれませんが、 kubectl に限らず、CI/CDの過程でなにがしかのコマ

はじめに 副業にてとある会社のLPを構築して以来、約2年間に渡ってほそぼそと機能追加やデザイン・文言の変更等をおこなってきたのですが、 元々保守性を意識した構造でないものに対して、場当たり的に修正を重ねてきてしまったため手を入れるのがしんどくなってきており、 そんな中で、 LPにページを増やしてほしい という依頼を受けたため、色々とリファクタリングに取り組んだのでその備忘録です✍ 私自身はデザイン・フロントエンド領域に明るくなく（別にバックエンドも明るくないが…インフラもか…）、抜本的な解決方法が思いつかなかったため、 今回は 既存実装の修正をできるだけ抑えつつ、保守性を向上させる仕組みを取り入れる という方針で頑張ってみることとしました🍦 現状 内容自体は1Pのシンプルなもので、以下のようなディレクトリ構造で管理しています クラウドソーシングでデザイン含めて初期実装をしてもらったものに