情報の見つけやすさを追求する - 社内ドキュメンテーションの階層整理術 - KAKEHASHI Tech Blog
カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回はチームに配属されて数ヶ月の私が、いかにして社内ドキュメンテーションの階層構造を整理し、情報の検索性を向上させたかについてお話します。 はじめに この記事の想定読者 課題意識 メンバーへの共有と相談 社外事例の調査 esa の階層整理 第 1・第 2 階層の整理 ストック情報とフロー情報を意識した階層の整理 esa の機能をフル活用する 効果や今後について はじめに カケハシでは全社的にドキュメンテーションツールとして esa - 自律的なチームのための情報共有サービス を利用しています。それぞれのチームやプロダクトごとに階層を切ってドキュメントを書いています。 プラットフォームチームでは認証基盤などの社内プラットフォームシステムを開発しているため、自チームが運用する各種
Datadogのグラフにデプロイタイミングを表示する方法 - 世界中の羊をかき集めて
Datadogのグラフをみていると、いつアプリケーションがデプロイされたのか気になることがあります。 「レスポンスタイムが急に悪くなってるけどデプロイ影響？」「エラーレートが跳ねるタイミングがあるけどデプロイ影響？」など。 そこでDatadogのグラフにデプロイタイミングを表示する方法を紹介します。 1, Event Overlays機能を使う docs.datadoghq.com 以下の画面のように、表示したいDatadog Eventのクエリを入力します。 するとEvent発生日時がグラフ上に縦線で表示されます。 シンプルな方法ですが、デプロイするタイミングでDatadogにEventを送信する必要があります。 デプロイフローに追加が必要なのでできればDatadog内で完結したいです。 2, Show Overlays機能を使う docs.datadoghq.com ※これを使うにはA
SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう
デプロイ対象環境ごとに別々のSlackチャンネルに通知するGitHub Actionsの実装例 - KAYAC Engineers' Blog
SREチームの長田です。 SRE関連の記事としては今年最初の記事になります。 今年も定期的にSREチームメンバーによる記事を投稿していく予定です。 よろしくお願いします。 さて、今回はGitHub Actionsのはなしです。 TL;DR デプロイを実行するGitHub Actionsの実行状況を デプロイ対象環境ごとに別々のSlackチャンネルに通知する場合の実装例として、 「slackapi/slack-github-actionで通知をつくりこむ」 「Actions Workflowを分ける」 「Actions Workflow実行の入り口を分ける」 の3つを紹介します。 背景 カヤックでは「まちのコイン」という地域通貨サービスを開発・運用しています。 coin.machino.co まちのコインの開発・運用チームの、特にサーバーサイドに関しては、 アプリケーションやインフラ構成の変
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
限られた人数で MIXI のあらゆる公式サイト群を保守・運用する ノウハウとその体制 | MIXI SRE秋祭り 〜 MIXIのもうひとつのSRE 〜
2023年10月31日に株式会社MIXIで行われた「MIXI SRE秋祭り 〜 MIXIのもうひとつのSRE 〜」での発表資料です。 イベントページ https://mixi.connpass.com/event/299121/ ─────────────── MIXIのSREは、サービスの信頼性に直接関わる負荷やコスト、システムの信頼性などをサービス開発と密接に連携しながら取り組むようなSREと、社内の共通課題やスポットで相談された事業などへの技術支援など、全社的なサービスの信頼性に関わるありとあらゆることに取り組むSREがいます。 本イベントでは、後者の全社的なサービスの信頼性に関わるSREから、最近の取り組み事例を紹介させていただき、Q&Aの時間などを通して、ご参加の皆様と共に情報交換ができれば幸いです。 ◎こんな方におすすめ◎ ・SREとしてサイト信頼性だけでなく、企画や事業開発な
ぼくのかんがえたさいきょうのGAS開発手法2023
前提clasp の制約、Script API の考え方、Google Drive の考え方に素直に従うその条件下である程度モダンな開発環境での開発を目指す 可能ならコードは VCS で管理する（pull-req など）ドキュメントベースで共同作業に向いた手法で開発を進める特にカジュアルに始めやすい Google Apps Script は悪い意味での属人化まっしぐらになりやすい。これが長期間の業務に影響しないような、ワンショットのものなら別にそれでもよいが、これが誰かに引き継がなければいけないような状況が生まれると一気に地獄みが増してしまうので、そうなってしまう前により良い開発手法を考えておきたい。 考慮したことGAS は素朴に作ると Script 本体の構造がそれを利用する container （例えば Spreadsheet）のデータ構造などと密結合になってしまう。この状態のままコード
MySQLを7000インスタンス規模で運用するLINEは、MySQL互換のNewSQLをどう評価したか？［PR］
MySQLを7000インスタンス規模で運用するLINEは、MySQL互換のNewSQLをどう評価したか？［PR］ コミュニケーションアプリ「LINE」をはじめ、多くの大規模サービスを運営するLINE株式会社は、LINEマンガやLINE GAME、LINEギフトなどをはじめとするLINE関連サービスのデータベース基盤として約7000ものMySQLインスタンスを運用しています。 このMySQLインスタンスの国内における管理と運用を行っているのが、MySQLコミュニティでも活躍する国内トップクラスのMySQLエキスパートを含む7名のITエンジニアで構成される「MySQL1チーム」です。 同チームのマネージャーである北川健太郎氏は、LINE関連サービスの発展に伴って増大するMySQLインスタンスの運用管理という課題に、日々のオペレーションの自動化を実現するための開発を積極的に行うことで対応している
SREとは？ Google Cloudがその基本を説明、JCBも導入／実践経験を紹介 (1/5)
グーグル・クラウド・ジャパン（Google Cloud）は2022年8月29日、グーグルが提唱する「SRE（Site Reliability Engineering、サイト信頼性エンジニアリング）」に関する記者説明会を開催した。グーグルからSREの基本な考え方が説明されたほか、ゲストとして実際にSREチームを組成しているジェーシービー（JCB）も出席し、SRE導入と実践の経験を紹介した。 SREとは？ システム運用チームとSREチームとはどう違うのか？ グーグル シニアデベロッパーリレーションズ エンジニアの山口能迪氏はまず、SREとは「本番システムを信頼性高く開発／運用するための一連のプラクティスと心構え、および職務を指す」言葉だと説明する。現在のような変化の多い時代においては、頻繁なサービス開発／リリースや、ユーザーニーズの変動に応じた急なスケール変更などが求められる。ただし、それらは
GitHubの運用を「会社」にしていく話
Ubie DiscoveryでSREなどをしている@itkqです。 UbieではGitホスティングにgithub.comを使っています。プロダクト開発に必要なprivateなコードベースはもちろん、OSSや就業規則といったドキュメントをpublicにホストしたりもしています。また、この記事を書いている時点で、メインのOrganizationのメンバーは121名です。 自分が入社したのは一年前（2021年1月）で、まだ情報システム専任の人がいませんでした。それから今に至るまで、GitHubの運用を「会社」にしていく話を書きます。 一年前のGitHubの運用 当時、UbieのOrganizationに所属していた人数は、業務委託含め80〜90名ぐらいで、Businessプランを利用していました。私はSREとして入社しましたが、情報システム専任の人がおらず、SREをはじめとする何名かのメンバーが
障害発生！全員集合？ － オンコールアンチパターンからの一歩前進 - Cybozu Inside Out | サイボウズエンジニアのブログ
8月だというのに涼しい日が続きますね。 kintone.comのDevOpsをしている@ueokandeです。 もうすぐAWS版kintoneのローンチからから2年が経過しようとしています。 この2年間、DevOpsチームではkintone.comのサービス安定化やスケーラビリティに注力してきました。 時には本番環境の障害で休日や深夜に障害対応することもあります。 kintone.comの障害の一次対応は、我々DevOpsメンバーが実施しています。 サービスローンチ直後は、メンバーの多くがオンコールに不慣れで、慌てて障害対応したりうまく進められないことが何度もありました。 そこでメンバー全員が効率的・効果的な障害対応を目指すべく、チームでPagerDuty社のIncident Response（非公式日本語訳版）を読むことにしました。 この記事ではAWS版kintoneで実際に体験した障害
SREって何？ これまでのシステム運用やDevOpsとは何が違うの？
近年、何かと話題に上がるSRE（Site Reliability Engineering）。しかし、「自分たちのチーム・組織に関係する話なのかよく分からない」「具体的に何をやればいいの？」といった感想を持つ方は多いのではないでしょうか。本連載では、そういった方に向けて、自社でSREチームの立ち上げを行った筆者が、SREの考え方 をご紹介します。また、連載の後半では、SREをいち早く取り入れた企業に導入背景などもインタビュー形式でお伝えする予定です。第一回となる本記事では、「SREって何？」「SREをやりたいが、どこからはじめればよいのか分からない」 方に向けて、SREの概観をご紹介します。 はじめに はじめまして。株式会社スタディスト SREチームの@katsuhisa__です。 スタディストでは、システム運用に関わる全般的な業務にはじまり、モニタリングやログ収集基盤の整備などを担当してい
スケールアウトの落とし穴から学ぶ、SREチームでのダッシュボードのアップデート術 - MonotaRO Tech Blog
どんなことが起こったのか？ モノタロウのサイトの監視について レイテンシ監視 トラフィック監視 エラー監視 リソース監視 ログ トラブルシュートの進め方 発生検知 発生箇所の特定 根本原因の調査 強化 課題 おわりに SREチームの市原(@ichi_taro3) です。 モノタロウでは、www.monotaro.com という大規模なECサイトを自社で開発、運用しています。 Webアプリケーションの運用ではトラブルはつきものです。今回は、とあるトラブルシュート事例を軸に、どのように運用を改善しているのかについて紹介します。 どんなことが起こったのか？ あるとき、モノタロウのWebサービス全体でレイテンシ悪化やバックエンドAPIへのタイムアウトの増加が頻発したことがありました。 当然これらは歓迎される状況ではなく、すぐに開発者やSRE、インフラチームの担当者が集まり調査を開始しました。現象は
運用に耐えられるコードを書くために - Magnolia Tech
オブジェクト指向とか、DDDとか言う前に、「落ちる時は速やかに落ちる」「原因がきちんと解析できる情報を出す」「リトライポイントが用意されている」「最終的な結果の正当性、整合性を確認する方法が用意されている」っていうコードをですね.... https://t.co/I5bIfhZYN8— magnoliak🍧 (@magnolia_k_) 2021年5月3日 異常系への対処がちゃんとできているコードが書けるようになってこそ一人前、みたいな、そんな価値観— magnoliak🍧 (@magnolia_k_) 2021年5月3日 いや、その手前の「つべこべ言わず、エラーが起きる可能性があるところは全てエラーコードをチェックする」なんだよ https://t.co/zmJBWR0ybX— magnoliak🍧 (@magnolia_k_) 2021年5月3日
プライベートクラウドの「ぴえん（;_;）」を解決 CyberAgent が開発した物理サーバーを管理するツール「Bearman」
Cloud Operator Days Tokyo は、クラウドの運用者に焦点を当てた技術者向けの新しいテックイベントです。プライベートクラウドの運用には、いろいろなつらさがあります。そのつらさを軽減するために、どのような運用をし、どのようなツールを使っているのか。CyberAgentのプラベートクラウド「Cycloud」を運用している中西氏が、そのノウハウを語ります。まずはプライベートクラウドにありがちな「ぴえん（;_;）」について。 自己紹介とアジェンダ 中西建登氏：「CyberAgentのプライベートクラウド Cycloudの運用及びモニタリングについて」というタイトルで、サイバーエージェントの中西から発表いたします。よろしくお願いします。 まず簡単に自己紹介です。中西建登と申します。インターネットではこちらのアイコンで活動しています。2019年からサイバーエージェントのPrivat
ソシャゲ運営の超基本｜ISHII RYOTARO
もう10年とは言わないけれど、７～８年くらい前からずっと言われていることなんだけど、未だに聞かれることがある業界ではとても当たり前と認識されている基本的な話があるんですが、未だにちょいちょい聞かれて話すことがあるんですよね。毎回同じことを言うのも飽きたのでnoteにまとめてみることにしました。 同業者の人からしたら、新人研修の内容にも入らないんじゃない？ってくらいに当たり前の事かと思うのでサラっと流してください。 普段、ゲームで遊んでる人はそうなんだって思うところもあるかもしれません。もし、将来はアプリゲームなどの開発・運営をしたいと思ってる人がいたら読んでみてもいいかもしれません。 売上を増やすという言葉の曖昧さフリートゥープレイ（F2P)や基本無料アイテム課金と呼ばれているゲームモデルは、ゲームを始めて遊ぶだけなら無料で遊べます。ただし、みんなが無料で遊んでいるとサービスが成立しません
latestタグのままdocker imageを本番運用してどうなったか - 京都行きたい
latestタグや書き換えるためのタグ（develop, stagingなど）を使って、本番で運用するのはやめましょう。 コンテナイメージのキャッシュ状況やリリースフローによっては予期しない形で 予期しないバージョンが本番で起動する可能性があります。 本記事では、どのプラットフォームやツールで発生したかについては記載しません。 本題はそこではないのと、そもそも運用が間違っているので 記述しても余計な枝葉になるからです。 この記事ではどういうことが起きたか、について書きます。 どういうことが起きたか サービスで、dockerイメージのlatestタグを使って本番運用していた。 全コンテナをgraceful restartしたようだ。（つもりだったが・・・） 別の作業中、管理画面の表示がおかしくなっているという話が出てきた。 そこで調べてもらったところ、なぜかリリースしたはずの機能が正常に機能
青山Pが振り返る「ドラゴンクエストX」3つの失敗――消すつもりのコードが本番環境に
翔泳社は2019年2月14～15日に「Developers Summit 2019」を開催した。本稿では、スクウェア・エニックスでドラゴンクエストXのプロデューサーを務める青山公士氏の講演「ドラゴンクエストXを支える失敗事例」の内容を要約してお伝えする。 青山氏は「ドラゴンクエストX オンライン」（以下、「ドラゴンクエストX」）で起きた3つの不具合とその原因を取り上げ、ドラゴンクエストX開発陣が不具合から得られた教訓を紹介した。 ドラゴンクエストXはどのように開発、実装されているか？ ドラゴンクエストXは、各ユーザーがゲームクライアントを通じてサーバに接続し、ゲームをプレイするMMORPG（Massively Multiplayer Online Role-Playing Game）だ。開発では、さまざまな機能拡張や期間限定イベントの実施を見据えて柔軟に対応できる「運営」と、不具合修正や障
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あんどぅ on Twitter: "本番運用するといずれ誰もがたどり着く、公式ドキュメントには書かれてないログ管理の現実解が資料化されていてすばらしい そう、CloudWatch LogsにはDev環境 or ERRORの場合のみ飛ばすFluentdの設定をすることで利便性と料金のバランスをとるのである これは公式ドキュメントにすべき https://t.co/RE4FmPCpJX"
ECS×Fargateで実現する運用コストほぼ0なコンテナ運用の仕組み/ ecs fargate low cost operation
