タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
「DevOps」とは？～概念が生まれた歴史背景～「DevOps」は、開発（Development）と運用（Operations）という言葉の組み合わせによる造語で、「デブオプス」と読みます。 DevOpsという概念を端的に説明すると、システムやソフトウェアの開発・運用の両担当者が密に連携し柔軟でスピーディーな開発と運用を実現するという考え方やその方法論になります。 現代の市場におけるニーズの変化の激しさ、そしてお客様・ユーザーのデジタルサービスに対する期待度の高まりを背景に、それに即したスピードでの開発が求められます。例えば、企画からリリースまでに数年かかってしまうと、その間にユーザーのニーズは変化し市場に受け入れてもらえないリスクが上がります。 一方で、スピード重視で開発した結果、仕様の不備や問題点が多いようであれば、それもまたユーザーに受け入れてもらえないということが発生します。 つま
何が起きたのか東部時間午前3時直前、PagerDutyは通知の失敗率の上昇を検知しました。当初は内部の認証関連の問題と推測されましたが、すぐにその可能性は排除されました。状況が展開するにつれ、これが上流プロバイダーで発生した大規模なイベントであることが明らかになりました。私たちの内部「インターネット気象」ダッシュボードは、複数のアカウントで通知トラフィックが通常と異なる急増を示しており、広範囲に影響が及んでいることを示唆していました。これは、ステータスページに表示される前に重大なインターネット障害が発生していることを特定する、信頼性の高いシグナルとなっていますが、根本原因までは教えてくれません。 インシデントが進行するにつれて、イベント、インシデント、通知の発生率が増加しているのを観測しました。通常、北米の大部分では夜間は低トラフィック期間となるため、イベントとインシデントのトラフィックは
PagerDuty on Tour TOKYO 2024での発表資料です。 https://www.pagerduty.co.jp/pagerdutyontourtokyo/
そもそも「オンコール」とは「オンコール(On-call)」とは、システム障害をもたらしうる「人による緊急対応が必要なインシデント」に即座に対応するために、インシデント対応者と対応時間をあらかじめ指定し管理する仕組みです。まず、インシデント対応とオンコールの基本についてご紹介します。 1. インシデント対応とは現代の私たちの生活は、ITサービスやシステムに大きく依存しています。例えば、医療システムの停止は人命にかかわる問題であり、ITサービスやシステムの安定した稼働や早急な障害対応は社会課題の一つとなっています。そんな「システム障害の予防と対応」において重要なのが、インシデント対応です。PagerDutyでは、インシデントを「システム障害に際して何らかの対応が必要な問題」と定義しています。早期にインシデント対応はシステム障害を未然に防ぐことに繋がります。また、適切なインシデント管理はシステム
調査結果によれば、企業内でAIの可能性についての議論はますます活発化している一方で、調査対象者の全員がAIに潜むセキュリティリスクについて懸念していると答えており、51％が生成AIの採用を適切なガイドラインが整うまで見送るべきだと回答した。 調査対象者は、先進技術の潜在的なビジネス上のメリットと未来についてもっとも関心を持つ立場であり、46％が早急に生成AIの採用を進めなければ、競合に遅れを取る恐れがあると考えている。一方で、4分の1の調査対象者が生成AIを信頼していないと回答した。 その他のおもな調査結果は以下の通り。 50％が企業の評判に生成AIがもたらすリスクについて懸念していると回答 51％が著作権や法的リスクが非常に不安であると回答 51％が適切なガイドラインが整備されるまで生成AIの導入は検討していないと回答 正式なガイドラインを策定済みの企業は29％に留まり、66％はこれらの
2024年8月6日（火） PagerDuty on Tour Engineer Session Customer Showcase 約10年間MIXIのインフラを 支えてきたPagerDutyの活用事例
Credit: NASA インシデントコマンダーになりたいですか。 あなたは正しい場所にたどり着けました！ インシデントコマンダーはシニアメンバーである必要はなく、必要な知識があれば誰でもなることができます（もちろんインターンも含みます）。 目的# インシデントコマンダーの目的を1文でまとめるなら インシデントを解決に導く インシデントコマンダーは重大インシデント発生中に意思決定をします。 インシデントを解決するために、タスクを委譲し内容領域専門家からの意見を聞きます。 日々の地位に関係なく、重大インシデントでは最も位の高い人です。 コマンダーとしての意思決定は確定的なものです。 インシデントコマンダーとしての仕事は、他の背景情報や詳細情報を集約して明確な調整をするために、通話を聞きインシデントのSlackルームを見ます。 インシデントコマンダーは、任意のアクションの実行や修正をしたり、グ
インシデント管理における「オンコール対応の重要性」オンコールとは、勤務時間外を含めて緊急対応が必要なインシデントに対応できるように、対応者や担当時間を決めておく仕組みです。 現在は、24時間365日稼働が前提となるシステムが多いなか、サービスの信頼性を守るには迅速なインシデント対応が求められます。仮にサービスが停止することになれば、機会喪失や顧客満足度低下を招くことになりかねません。そのため、インシデント管理においては速やかに対応が行える、オンコール対応が重要です。 なお、システムで起こり得るインシデントの種類は、以下の記事でも解説しています。 「インシデント対応」とは？ 〜効率的な体制構築のポイントを解説〜 また、インシデント管理については以下の記事で解説しているので、ぜひ併せてご覧ください。 「インシデント管理」とは？〜システム障害を未然に防ごう〜 エンジニアがオンコール対応に不安を感
よくある「インシデント管理」の悩みシステム運用には、運用担当をはじめ、開発担当やその双方を担当するDevOpsエンジニアなど様々な役割の人々が関わっています。ここでは、インシデント管理やインシデント対応にあたって、主にシステムを運用する企業が抱える、よくある課題や悩みを3つ紹介します。 1. インシデントへの対応開始・解決の複雑化ITシステムを運用するために自社のサーバを利用するオンプレミスや、複数事業者のクラウドシステムを混在させて利用するマルチクラウドなど、利用するサービスそのものが多岐にわたり、年々複雑になる傾向が強まっています。 自社が運用するシステムが複雑になったことで予期せぬ課題が増え、様々な監視ツールから送られてくる大量のアラートに対応しなくてはいけません。監視ツールが異なると、各アラートの詳細や関連情報を調査するためのツールも異なり、インシデントを特定するまでに時間を要した
Incident ManagementAIや自動化を活用し、インシデント対応を効率化することで、運用・開発チームの担当者は少ない労力で速やかに障害を解決できるようになります。 Customer Service Opsカスタマーサービスチームのオペレーションを最適化し、顧客満足度の向上と業務効率化を実現します。社内のインシデント対応状況をリアルタイムで把握し、顧客に伝えることで顧客満足度を向上させます。
こんにちは！NewsPicksエンジニアの森川です。今回はNewsPicksのオンコール(=障害対応)体制の変遷と試行錯誤をご紹介したいと思います。 オンコール1.0 ~ 全員野球時代 ~ オンコール2.0 ~ 当番制時代 ~ 1. 専門外のアラートに対応できない 2. 対応するエラーの数が多すぎる 3. 勤務時間の自由度が減る 4. slackに気づけない オンコール3.0 ~ PagerDuty時代 ~ 1. アラートを緊急度で仕分け 2. 当番ローテーションの変更 3. PagerDutyの導入 おわりに オンコール1.0 ~ 全員野球時代 ~ NewsPicksにはエンジニア全員が入るslackチャンネルがあり、ここで周知事項の共有や雑談、問い合わせがされています。昔はこれに加え不具合の報告や監視システムからのアラート通知もこのチャンネルに流れるようになっており、アラート通知は気づ
SREとはなにか？「SRE（Site Reliability Engineering）」とはシステム運用方法の一つで、日本語では「サイト信頼性エンジニアリング」といいます。2004年に、Google社がWebサイトの安定的な運用を支えるための方法論として、提唱しました。 SREの大きな特徴は、「信頼性」をシステムの重要な機能の一つとしてとらえている点です。システムの信頼性を確保し、より良いサービス提供につなげるためのツールやアプローチ方法を常に模索します。 例えば、煩雑な手作業や繰り返し作業の削減、ソフトウェアを用いたITインフラのシステム自動化などに注力します。ユーザーがシステムを安心して使い続けられること、現場の負担を抑えながら信頼性の高いシステムを提供できることは、SREがもたらす代表的なベネフィットに挙げられます。 SREはなぜ求められるのか？必要とされる背景SREが提唱される以前
インシデント対応プラットフォームとして知られるPagerDutyに、Product Evangelistとして入社した。 www.pagerduty.co.jp ▲マスコットのペイジーくん Evangelistを仕事にするよ コミュニティ活動で知り合った人からは、「お、ついに本職になるんだね」と、あまり違和感なく受け入れられるんじゃないかなと思っている。むしろ、「今まではDevRelじゃなかったのか」とまで思われるかもしれない。そう、これまではPre-sales Engineerだったし、それより前はProfessional Serviceだったので本業におけるコミュニティ活動はあくまでもボランティアだったのだ。 逆に、自分と付き合いが長い人からすると「え、DevRel? おまえDevRelにはならないって言ってなかったっけ？」と驚かれるんじゃないかと思う。そう、自分はDevRelにはなら
概念理解編1️⃣ システム障害とは？〜企業が考えるべきリスク対策とインシデント管理〜企業にとって甚大な損失とともに伝えられるシステム障害のニュースを耳にすると、自社のシステム障害対策に不安を覚える方もいるのではないでしょうか。現代のシステム障害対策では、予防策に加え、より迅速な障害対応が求められます。システム障害が発生すると大きな損失につながり、1分1秒でも早い復旧が望まれるためです。そこで、システム障害の対策と対応において重要性が増しているのが「インシデント管理」です。適切なインシデント管理は、サービスの正常な利用を妨げるあらゆる事象への素早い対応を実現し、迅速な復旧につながります。本記事では、システム障害のリスクや対応策、そしてシステム障害への対策を考える際に知っておきたい「インシデント管理」とは何かを解説します。 ✅記事はコチラ 2️⃣ 「DevOps」とは？〜超基本から実践のポイン
Incident ManagementAIや自動化を活用し、インシデント対応を効率化することで、運用・開発チームの担当者は少ない労力で速やかに障害を解決できるようになります。 Customer Service Opsカスタマーサービスチームのオペレーションを最適化し、顧客満足度の向上と業務効率化を実現します。社内のインシデント対応状況をリアルタイムで把握し、顧客に伝えることで顧客満足度を向上させます。
はじめに こんにちは！freee の Enabling SRE チームに所属している阿部 寛明 (uryy)と申します。freeeのシステムを運用する際にはDatadogからの通知をもとにアラート対応するケースが多いのですが、組織拡大により従来の方法ではうまくワークしない箇所もでてきたので改善に取り組んでおります。今回はその一環で進めているPagerDuty導入の取り組みとその際に気づいたTipsについて紹介します。 PagerDutyについて PagerDutyは監視ツールやアプリケーションからのアラートを受けてインシデント発生を担当者にオンコール通知するプラットフォームサービスです。オンコール機能だけでなく、受け取ったアラートのトリアージやシフトに基づいたエスカレーションも可能となっています。freeeでは下記図のようなシステム連携の環境構築を進めています。 システム連携イメージ 現在
これはPagerDutyで利用している標準的なポストモーテムのテンプレートです。 それぞれのセクションでは、あなたがポストモーテムに書くべき情報について説明します。 ガイドライン このページはインシデント発生後5営業日以内に設定されるポストモーテムのミーティングで確認することを目的とします。 最初のステップはインシデント発生の5営業日以内に、共有カレンダーにミーティングを設定することです。 情報が埋まるまでミーティングの設定を待ってはいけませんが、ミーティングまでにページができているようにしてください。 ** ポストモーテムのオーナー:** ここにはあなたの名前が入ります。 ** ミーティングの対象:** インシデント発生後5営業日以内に、「インシデントポストモーテムミーティング」を共有カレンダーにスケジュールします。ここに日付を入力してください ** 通話の記録:** インシデントの通話
Incident ManagementAIや自動化を活用し、インシデント対応を効率化することで、運用・開発チームの担当者は少ない労力で速やかに障害を解決できるようになります。 Customer Service Opsカスタマーサービスチームのオペレーションを最適化し、顧客満足度の向上と業務効率化を実現します。社内のインシデント対応状況をリアルタイムで把握し、顧客に伝えることで顧客満足度を向上させます。
お知らせ connpassプライバシーポリシーの改定及び外部送信規律ページを追加いたしました。詳細につきましてはこちらをご覧ください。 新機能 技術カンファレンスをより見つけやすく、参加しやすくするための新機能「カンファレンス特集ページ」をリリースしました。「技術」や「テーマ」などのトピック別に探せるほか、直近開催予定のカンファレンスが一覧で確認できますのでご活用ください。詳しい機能説明や掲載方法についてはこちらをご確認ください。
こんにちは！ 株式会社ココナラのHead of Informationに任命された ゆーた（@yuta_k0911）です。 PagerDuty Advent Calendar 2023の18日目の記事です！ ココナラでは2016年からPagerDutyを使っています。（私が入社する4年も前から・・・） PagerDuty導入以前のオンコール運用や導入後から現在に至るまでどのような利用・工夫をしていて、今後どう利活用しようとしているか？をアドベントカレンダーの記事にしてみます！ 私の推し機能も紹介します。 ぜひ、PagerDutyを利用検討中の方もご覧ください！ 実は会社名義でアドベントカレンダーに参加するのはこれが初めてです💦 初歩的な内容が多いと思いますが、お付き合いください🙇♂ ココナラでのPagerDutyの使い方 PagerDutyを使い始めたのは私が着任する前ですので、想像
こんにちは。asken でインフラエンジニアをしている沼沢です。 今回は、緊急性の高いアラートを検知した際の電話連絡の仕組みについてお話します。 抱えていた課題 弊社では、元々システム監視はしていたものの、検知時はメールや Slack の通知に留まっており、システムが深刻な状態となった場合に架電する仕組みがありませんでした。 休日や夜間に深刻な状態となった場合にメールや Slack 通知だけでは気付きづらく、早急に対処しなければならない状況の検知が遅れる懸念がありました。 検討したソリューション Twilio まず、自身が利用したことのある Twilio を使った架電を検討しました。 しかし思い出したのは、電話番号取得時に日本の法に準拠するために必要な各種手続きの面倒さでした。 https://support.twilio.com/hc/en-us/articles/44061586621
Incident ManagementAIや自動化を活用し、インシデント対応を効率化することで、運用・開発チームの担当者は少ない労力で速やかに障害を解決できるようになります。 Customer Service Opsカスタマーサービスチームのオペレーションを最適化し、顧客満足度の向上と業務効率化を実現します。社内のインシデント対応状況をリアルタイムで把握し、顧客に伝えることで顧客満足度を向上させます。
EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。
大阪オフィスの玉井です。 dbt Cloudの利用が本格的になってくると、ジョブが何らかのエラーでこけた場合、早急な対応が求められてくると思います（データ変換が止まる→BIツールや機械学習等といった下流のデータ利用に支障が出る→ビジネス的にヤバい）。 そういうユーザーのために、dbt Cloudには、ジョブが失敗したときの通知の仕組みに関する機能が色々用意されています。その中でも、今回はPagerDutyと連携する方法を実際に試してみました。 やることの概要 Webhookを利用する 最近（2023年3月現在）、dbt CloudのジョブがWebhookに対応しました。 これまでは、dbt側のAPIを定期的にポーリングする等して、こちら側が能動的にジョブのステータスを確認する必要がありました。しかし、Webhookに対応してくれたおかげで、こちら側から定期的に確認せずとも、ジョブがこけたタ
Home オンコールについて インシデント発生前 インシデント発生中 インシデント解決後 危機対応 トレーニング その他の情報 Getting Started On-Call Being On-Call Who's On-Call? Alerting Principles Before an Incident What is an Incident? Severity Levels Different Roles Call Etiquette Complex Incidents During an Incident During an Incident External Communication Guidelines Security Incident After an Incident After an Incident Postmortem Process Postmortem Te
複雑さを増すシステム環境における「ランブックの重要性」まず、ランブックとはどのようなものなのか、ランブックの必要性と併せて解説します。 ランブック(Runbook)とはランブックとは、「プロビジョニング」「ソフトウェアの更新・展開」「構成変更」「ポートの解放」といった、頻繁に発生するIT業務の手順を詳細に記した説明書のことです。ランブックの形式は、おもに次の3つに分けられます。 マニュアル形式：手順を説明した担当者向けの説明書半自動形式：一部のワークフローが自動化された担当者向けの説明書完全自動形式：すべてのワークフローが自動化された、担当者を必要としないものの説明書ランブックは料理のレシピのように、特定の業務を迅速かつ効率的に進めるための経験に基づいた詳細な手順が書かれています。ランブックがあれば、経験豊富なメンバーの知識を新しいメンバーに共有でき、経験の浅いメンバーでも頻繁に発生する問
Don't wait for 2027: Switch from Opsgenie to PagerDuty today (migration services available). Learn more
こんにちは。次世代システム研究室のM.Mです。 近頃のWEBサービスは、他社のサービスや自社でも他グループのサービスと連携して構成されているケースが多いのではないでしょうか？ サービス間同士の連携について意識した設計がされていないと、あるサービスがダウンしたら、引きずられて私たちが開発・運用するサービスも提供できない状態になってしまうことがあります。 その逆もあり、私たちが開発・運用するサービスがダウンしたら、連携しているサービスも提供できなくなってしまうこともあります。 もちろんそのような障害が発生しないような設計や対策をすることも重要ではありますが、特に障害発生後に盛り上がる問題があります。 障害に気づくのが遅い。 障害の連絡がない。遅い。 誰が対応しているのか分からない。 状況確認したくて連絡するが、担当者につながらない。 私たちが開発・運用するサービスの障害に、私たちより先に連携し
大学卒業後、コンピュータネットワーク機器開発のグローバル大手企業に入社。10年以上ネットワークエンジニアリングにおけるプリセールス業務に従事した後、コンテンツデリバリーネットワークを開発・提供する米企業へと転職し、国内プラットフォーム事業を展開する顧客へのプリセールス業務と、日本チームのマネジメント業務に従事。2022年5月のPagerDuty日本支社立ち上げのタイミングより現職に就き、営業メンバーと共にプロダクト導入までの支援を技術的にサポートしている。 システム障害からリコール対応まで、幅広く活用されているPagerDuty 水井 悠太（以下、水井）：本日はよろしくお願いします！Qiita社は長年利用していますが、読者の中にはPagerDutyを知らない方もいると思いますので、改めてPagerDutyの概要と他社ソリューションと比較した際の特徴を教えてください。 山田 索 氏（以下、山
おさらい: インシデントコマンダーとは前回のおさらいをしましょう。インシデントコマンダーを一言で説明すると インシデントを解決に導く指揮官 です。重大なインシデントが発生した際、インシデント対応プロセスの全体を管理し、関係者間の調整とコミュニケーションを行い、出来る限り早くインシデントを解消に導くのが責務です。 インシデントコマンダーの役割意思決定作業担当への指示作業要員や関連部署の招集・体制構築ステークホルダーとのコミュニケーション状況の交通整理インシデントの発生と収束の宣言ポストモーテムの作成指示インシデント発生時の対応の流れインシデントが発生した際、インシデントコマンダーは状況を素早く把握し、適切な対応を取ることが求められます。ここでは、インシデントコマンダーが進めるべき対応の流れを説明します。 1️⃣ 状況の把握（Size-Up）まず、インシデントの症状を特定し、影響範囲を確認しま
4月10日に開催されたカンファレンスPagerDuty on Tourの中で、サービス運用における障害対応力を競うPagerDuty Challenge Cupが行われた。ゲーム形式のイベントは、PagerDutyとしてはグローバルでも初の試みとなるという。障害対応では、技術力だけでなく、ドキュメント化のスキルや、コミュニケーション力も問われる。現場で起こり得る、リアルなシチュエーションまで再現した競技に、SREたちはどう挑んだのか。 障害対応の総合力を競う「現場あるある」を想定したルール PagerDuty Challenge Cupとは、PagerDutyの機能を活用しながら、各企業の現場で活躍するエンジニア3名がチームとなり、障害対応の成熟度を競う体験型の大会だ。各チームは架空のチャットサービスを運用している担当者という設定で参加する。このサービスにはランダムに障害が発生するため、9
PagerDuty x Amazon GuardDutyでSaaSを利用したGuardDutyのインシデント管理を体験してみませんか？？ みなさん、こんにちは。 明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。 みなさん、インシデント管理していますか？ AWS上のシステムを安定稼働させるために、サーバーメトリクス、ログ、セキュリティなどをはじめとした項目の監視は必須ですよね。 AWSにおける監視サービスといえばCloudWatchがありますが、リソースを監視をより楽にするツールはAWS以外にたくさんあるため、運用負荷を軽減するためのツールの導入を進めていくとアラートを検知した際の通知や煩雑になってきます。 さらに、インシデントが起きた際はさまざまな監視ツールでアラートが検知されることもあると思います。その度複数のツールを行き来していると疲弊してしまうで
この記事はPagerDuty Advent Calendar 2023の25日目の記事です。 PagerDutyのオンコールシフトをSlackでリマインドしたい 🎄メリークリスマス🎅 NewsPicksのSREチームで障害対応をよくやっているあんどぅといいます。 先日、ゆるSRE勉強会 #3という勉強会でNewsPicksの開発組織のオンコールの体制とポストモーテムの取り組みを発表させていただきまして、その文脈でPagerDutyをどのように活用しているのかを実装とともにご紹介させていただきます。 弊社ではモバイル担当1名サーバー担当2名の3名のエンジニアが一週間に2交代制(3.5日シフト)でオンコールを担当します。オンコール担当のことを運用当番と呼んでいるのですが、PagerDutyのオンコール設定は非常〜に便利なので 3.5日のうち有給取得するので1日だけOverride Laye
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
