ABEMAとZTVのユースケースに感動しきりのGrafana Meetup Japan #3 開催レポート #grafanaJP | DevelopersIO
いつも通り、メインセッション2つとLT4つの構成ですが、相変わらず時間が押してしまって、19時開始のイベントにしては欲張り過ぎなのかもしれません。本当にどのセッションも熱量が高く参考になるものが多かったので、コンテンツ減らしたくないなぁというのも悩みどころだったりします。 会場の様子。メインディスプレイが大きくて視認性抜群。天井から吊り下がっているサブディスプレイも複数設置の贅沢なセミナー専用ルームで、イベント利用としては最高の環境でした。改めてオラクル様に感謝。 当日のアーカイブ動画。配信は安定のEMTEC - IT勉強会特化の配信チームです。いつも本当にありがとうございます！ 実施協力は、こちらの4団体。 アンケートやツイートの投稿などを司会から誘導した後に、ビッグニュースが会場でお知らせされました。 2025年2月25日に、Grafana Labs公式イベントが日本で開催されます 冒
メンテナンス画面の表示方法いろいろ | 外道父の匠
コンテナの話（AWSコンテナ系アーキテクチャの選択肢を最適化する）をした時にメンテナンス画面の表示についても軽く触れました。 改めて整理すると他にもいろいろあるということで、上から順に超ザックリと並べていきたいと思います。一応 AWS でを想定していますが、一般的な方法論でもあるので、どこだろうと何かしらの足しにはなるかもです。 条件 どのようなメンテナンス状態にしたいかによりますが、満たすべき条件はおそらくこのようなものがありますよ、ということで整理します。 １回の変更操作で、一括したメンテインを保証すること 管理者はメンテにならず通常アクセスする手段があること メンテ機能の仕込みによって悪影響がないこと 希望するメンテ用レスポンス内容を実現可能であること 静的 or 動的 Status Code 503 Content-Type レスポンス・サイズ 例えば DNS のレコード値を変更し
【資料公開】Classmethod Odyssey で「監視と可観測性の違い」そして「運用上の優秀性」について語りました #cm_odyssey | DevelopersIO
みなさん、監視してますか！（挨拶 過日行われた弊社イベント「Classmethod Odysssey」、そのひとつで 7/18 に行われたオンラインイベント「Day7 運用・監視編」にて、表題のタイトルで登壇してきました。 その時の資料を公開いたします。 セッション概要： あなたの大切なシステムに必要なのは、監視（モニタリング）でしょうか、それとも可観測性（オブザーバビリティ）でしょうか？ 「え、同じじゃないの？」「進化版でしょ？」と思われた方も多いでしょう。「運用の優秀性」5つのドメインにひも付けながら、「いま」と「将来」のための監視を考えていきます 当日は通して数十名の方に御拝聴いただきました。 本当にありがとうございました！ みどころ このセッションを通じて言いたかったことは、 「監視」と「可観測性（オブザーバビリティ）」は相互に補完するもの 「運用上の優秀性（ Operationa
ITシステムの可用性と損失を考える | 外道父の匠
数値上はこうなるものの、意図的な短期的メンテナンスや、意図しない障害でも１回あたりの期間が短ければ、その期間に積まれるはずだった売上は、その復帰後に売り上がる場合も多いでしょう。その辺りは、ユーザーの信頼を損なわない方法や運用を心がけることで、十分に埋められる可能性を含む性質です。 しかしこれが、あまりに高頻度であったり長期間になると、その復帰後に停止期間分を含めた売り上げにならず、そのまま機会損失となる可能性が高まります。いわゆるユーザー離れというやつです。その損失だけで済めばまだマシで、普通に考えればその後に想定していた売上も減少し続け、元に戻すには相応の時間と労力を伴うでしょうから、数値以上の痛手となるはずです。 こう考えていくと、運用関係者が健全であれば、無理に100％の可用性を目指さず少なくとも合計99％以上となる停止猶予を持たせた運用とし、数日を跨ぐような連続した長期間の停止だ
エンジニア運用工数40%削減！Bill One における運用改善のとりくみ - Sansan Tech Blog
Bill One Engineering Unitの田上です。運用改善と題したプロジェクトによって、エンジニアの運用工数を半年で40%削減することに成功したので、今回はその取り組みをご紹介します。 背景 Bill One のエンジニアリング組織では、フルサイクルエンジアリングで開発と運用を行っており、開発者自身が運用対応（本番環境で発生したエラーの調査・対応、ユーザからの依頼・問い合わせの対応など）を行っています。 エンジニアが自身の開発したプロダクトへのフィードバックを迅速かつダイレクトに受け取れる非常に良い方式ではあるのですが、その対応工数があまりにも多くなりすぎて開発工数が逼迫するようになっていました。 その状況をどうにかするため半年の期限付き特命チームとして運用改善チームを立ち上げることにしました。 立ち上げ 組織内のフラストレーションの高まりを背景に、2名のエンジニアが新たなチー
【2024年度 サイバーエージェント 新卒研修】システム運用の基本と戦略
株式会社サイバーエージェントAI事業本部の2024年度 エンジニア新卒研修でシステム運用の基本と戦略に関する講義を行いました。
教科書を読んだだけでは分からないSRE推進の取り組みを公開！──SHIFT・X-Tech5・NTTデータのエンジニアが語った事例も紹介 - TECH PLAY Magazine
Google社が提唱したITシステムの構築や運用のアプローチ方法であるSRE。導入する企業も増えてきた一方で、期待する効果が得られていない企業も少なくない。そこで今回は、SHIFT、X-Tech5、NTTデータのエンジニアに、導入事例を交えながら、SREの推進・定着・効果などについて語ってもらった。 SREsのためのSRE定着ガイド──X-Tech5 株式会社X-Tech5 取締役CTO 馬場 俊彰氏 最初に登壇したのは、X-Tech5の馬場俊彰氏だ。システムの運用フェーズに携わること、特にモニタリング、オブザーバビリティ、パフォーマンスチューニングが大好きだというCTO馬場氏。iCARE社の技術顧問も務め、専門領域に関する著書を多数上梓している。 馬場氏はまず「SRE（Site Reliability Engineering）とは何か」を関連本を紹介しながら、こう述べた。 「SREはDe
サイバーエージェント、新卒エンジニアの研修資料を2つ無料公開 「システム運用」と「オブザーバビリティ」を解説
関連記事 上司や部下に読ませたい？ とある地方自治体の「会議改善に関するガイドライン」が分かりやすいと話題に 新潟県柏崎市が公開した「会議改善に関するガイドライン」が、Xやはてなブックマークで話題だ。同市がDXに伴う既存業務の見直しに当たって、会議の質を向上するために策定したもので、SNSなどでは「自治体からこれが出てくるのは画期的」「同僚や役員に読ませたい」といった声も出ている。 「テスト文字列にうんこと入れるな」──ゲーム会社の新卒向け資料“2024年版”が公開 テスト環境で悪ふざけするリスク説く 「テスト文字列にうんこと入れるな」──そんなふうに訴える新入社員向けの研修資料の2024年版が公開中だ。軽い気持ちで入れたテスト文字列が社外に漏えいした際のリスクについて説明した資料で、新たに事例などを加筆している。 早速出たぞ、24年度研修資料 新卒向け「エンジニア基礎」、ウィルゲートが公
大活躍中の若手エンジニアが明かす！ゲームバックエンドの裏側とハイパフォーマンスな働き方について を実施しました - COLOPL Tech Blog
2023年10月30日、「大活躍中の若手エンジニアが明かす！ゲームバックエンドの裏側とハイパフォーマンスな働き方について」というタイトルのイベントを実施いたしました。 アーカイブ当日の放送内容は YouTube でご覧いただけます。 www.youtube.com イベントの内容 今回のイベントでは、新卒入社した4名の若手バックエンドエンジニアから、入社後に発揮したパフォーマンスの振り返りや、実際に行っている業務の裏側についてお話しいたしました。 新卒3年目のゲームバックエンドエンジニアがこれまでに経験したこと 1つめの発表は、2021年に新卒入社したバックエンドエンジニアがこれまでに経験したことを振り返る内容でした。 運用ゲームの開発では実際にどのようなことを行っているのかを紹介し、その中で起きた失敗や、そこから学んだことをまとめて発表しました。 speakerdeck.com 大規模タ
クラウドリソースのコスト増加は“自動化”で解消 タグの自動付与で実現した「シン棚卸システム」
自己紹介 村上颯人氏（以下、村上）：それでは、「タグ！ タグ！ タグ！ AWSリソースへのタグ自動付与による、ちりも積もれば山と“せぬ”コスト削減の術～」と題して、NTT東日本の阿部と村上が発表します。 まずは自己紹介します。最初に、本日のテーマや背景などを説明する、村上颯人と申します。そして、後に今日紹介するシステムの詳細を説明する阿部綾香。この2名で発表します。所属は2人とも設備企画部というところで、主にパブリッククラウドを使用したソリューション開発や運用業務を行っています。よろしくお願いします。 クラウドリソースの棚卸活動の悩みを解決する「棚卸の極意」 では、本日のテーマになります。クラウド運用者のみなさんであれば、このような経験をしたことはないでしょうか？ 「あれ？ 今月のクラウドの使用料、やたら高いな、なんでだ？」。そしてよく見ると、「あっ、なんか使ってないのに稼働し続けているリ
「ダッシュボード」は「設計」「構築」などと同じくらい重要である Amazonのダッシュボード活用のポイント2つ
技術記事『Amazon Builders' Library』にフォーカスを当てた勉強会「AWS Tech talk Night#5 クラウドネイティブ時代のエンジニアが押さえておきたい ソフトウェアの構築・運用で考慮すべき5つのポイント 〜AWSプリンシパルエンジニアの技術記事をソリューションアーキテクトが解説〜」。ここで、ソリューションアーキテクトの吉澤氏が登壇。まずはAmazonがダッシュボードを重要視している理由と、実際の活用のポイントについて話します。 吉澤氏の自己紹介 吉澤巧氏（以下、吉澤）：それでは「Amazonにおけるダッシュボードのベストプラクティス」というタイトルで、アマゾンウェブサービスジャパン、ソリューションアーキテクトの吉澤からお話しします。 まずは簡単に自己紹介です。私は2022年に新卒で入社した吉澤といいます。現在はソリューションアーキテクトというポジションで働
社内のソースコードをGitHub Enterprise にとりまとめてる話 - NTT Communications Engineers' Blog
みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。 この記事は、NTT Communications Advent Calendar 2021 2日目の記事です。 今回は社内のソースコードを GitHub Enterprise にとりまとめる活動とそこで遭遇した課題と解決方法についてお話します。 背景 きっかけは「NeWork のソースコードが見たい」という私の思いつきでした。 これを私が言い出した 2020 年当時、NTT Com ではソースコード管理の方法に決まりはなく、各プロジェクトの判断でバラバラにソースコードリポジトリが導入されていました。ちなみに、私が社内で見かけただけでもソースコードのホスティング先には以下のようなものがありました。 GitHub (Team plan) Git
GitHub Actions の storage の容量がいっぱいになった時の対処方法とエコな運用 Tips - BEACHSIDE BLOG
GitHub Actions を何気に使ってると、Storage の容量がいっぱいになって GitHub Actions がエラーで実行できなかったり、ストレージの課金をせねばあかんのかと迫られることがあります。 こんな時の確認方法や対処方法と、運用で考慮しておきたい Tips を書いていきます。 記事の前半に利用制限に関して知っておきたい基礎知識、後半でエラーで使えなくなった GitHub Actions を使えるようにする方法や運用の Tips を書いていきます。 🚀 GitHub Actions の制限に関する基礎知識 Storage のリミットを超えたときのエラーメッセージ？ 実行時間の超過について 使用量の確認方法 Organization をもたないアカウントの場合 余談: GitHub Packages は転送量の制限もある Organization があるアカウントの場合
Darklaunchという便利なものと、その未来 - スタディサプリ Product Team Blog
Darklaunchという便利なものと、その未来 3行要約 スタディサプリのRubyバックエンドで気軽に誰でも使える、"Darklaunch"という Feature toggles 機構がある 4年強ほど運用してきて、様々な知見、多様なユースケース、問題などが明らかになった 知見を活かして、近い将来Darklaunch v2というのを社内で作って公開予定 (HTTP APIであり、Rubyバックエンドだけでなく全環境から直接利用可能) Feature togglesとは Feature togglesとかFeature flagsとかchankoとかcanary releaseとかA/BテストとかlaunchdarklyとかflipperとかDarklaunchなどという言葉を見聞きした機会のある方は多いと思います。ちょっとそれぞれレイヤーやカバレッジは違いますが、ようするに「コードの変更
サイバーエージェントのGitHub活用 ～ 導入から運用体制、開発フロー、勉強会による現場への普及活動まで
また、Organization[1]の数も360を超え[2]、リポジトリ数もOrganizationのものだけでも2000近く作られています[3]。 新規のプロジェクトは基本的にGitを利用しており、既存プロジェクトもほとんどがSubversion（以下SVN）などからGitに移行しました。 本記事では、Ameba事業本部がどのようにGitを組織内に普及させていったか、その運用体制、現場でどのように利用されているのかをご紹介します。 [1] 複数アカウントをまとめるグループ機能です。リポジトリは個人単位だけでなく、Organization単位で作ることもできます。 [2] プロジェクト単位で1つのOrganizationを用意しています。 [3] 個人アカウントで作成したり、他からforkしたリポジトリは除いた数です。 GitHub Enterprise導入への道のり GHE導入以前の標準
長期運用に寄り添うインシデント対応を考える - エムスリーテックブログ
こんにちは！ エムスリーエンジニアリンググループ、 SRE チームの平岡(@uhtter)です。 こちらは エムスリー Advent Calendar 2022 の15日目の記事になります。 SRE が担当するの重要なタスクの1つに、インシデント対応があります。 インシデント対応では、システム・サービスの可用性・継続性を損なう問題（インシデント）が発生した際、それをアラートとして受け取り、問題を解消してすみやかにサービスが継続できる状態に復旧します。 SRE 本 でも、 SRE として配属された新人がまず目指すべきは「オンコール業務（≒インシデント対応）をこなせるようになること」と示唆されていますし、それをサポートする組織的なプロセスやトレーニングの方法が数多く紹介されています。 それらを踏まえても、インシデント対応の重要性については改めて問うべくもないでしょう。 エムスリーでは、2000
AWS RDS/AuroraのDDL運用を最適化する | 外道父の匠
AWS re:Invent 2022 にて RDS の Blue/Green が発表されたことを受けて、この辺の具体的な運用をどのように改善できるのか考えていきます。 たいした内容ではないですが、丁寧に最適化して慣れれば、それなりに強い効果を発揮できそうな感じはあります。 ALTER TABLE の辛み まず復習からですが、RDS に Blue/Green が実装されるほど辛い運用はなんだったかというと、重い ALTER TABLE にあります。 ALTER には色々あるのでアレですが大雑把に言うと、容量や行数が大きいテーブルに対して実行すると、数時間単位～の処理時間がかかることが多く、しかもパッと見で進捗を把握できないという問題を抱えていました。それに対して色んな対策を取っていたと思います。例えば…… Handler_write SHOW GLOBAL STATUS LIKE ‘Hand
コロプラのゲーム開発/運用におけるツール/機能の一部を紹介（管理ツール編） - COLOPL Tech Blog
コロプラでは、日々のタイトル運用を円滑に行うため、ゲームアプリケーションを支える多くのツール群を用意しています。 以前「コロプラのゲーム開発/運用におけるツール/機能の一部を紹介」という記事で開発を支援するツール・機能を紹介しました。 前回はゲーム開発者向けのツールについての話が中心でしたが、今回は「マスターデータ操作」「お問い合わせ・調査対応」といった機能を提供するゲーム運用者向けのツール（以下：管理ツール）について取り上げたいと思います。 管理ツールについて コロプラでは運用チームが、ゲームデータの設定や調査業務などの運用作業を画面上で行えるようにするための「管理ツール」と呼ばれる運用ツールが存在します。 管理ツールでは業務システムやWEBアプリケーション等における管理画面の機能に加えて、デバッグ機能や補填機能のようなモバイルゲーム特有の要件の機能にも対応しています。 以降の章では、管
Kubernetesの負荷試験で絶対に担保したい13のチェックリスト - Enjoy Architecting
概要 ここ最近、Kubernetesクラスタを本番運用するにあたって負荷試験を行ってきました。 Kubernetesクラスタに乗せるアプリケーションの負荷試験は、通常の負荷試験でよく用いられる観点に加えて、クラスタ特有の観点も確認していく必要があります。 適切にクラスタやPodが設定されていない場合、意図しないダウンタイムが発生したり、想定する性能を出すことができません。 そこで私が設計した観点を、汎用的に様々なPJでも応用できるよう整理しました。 一定の負荷、スパイク的な負荷をかけつつ、主に下記の観点を重点的に記載します。 Podの性能 Podのスケーラビリティ クラスタのスケーラビリティ システムとしての可用性 本記事ではこれらの観点のチェックリスト的に使えるものとしてまとめてみます。 確認観点 攻撃ツール 1: ボトルネックになりえないこと Podレベル 2: 想定レイテンシでレスポ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubセキュリティ Organization運用のベストプラクティス
