株式会社サイバーエージェントAI事業本部の2024年度 エンジニア新卒研修でシステム運用の基本と戦略に関する講義を行いました。
【2024年度 サイバーエージェント 新卒研修】システム運用の基本と戦略
株式会社サイバーエージェントAI事業本部の2024年度 エンジニア新卒研修でシステム運用の基本と戦略に関する講義を行いました。
オンコール対応とは？〜現場担当者が語るオンコール対応の不安解消方法を解説!～|インシデント管理プラットフォーム│PagerDuty
DevOpsの導入によって、開発エンジニアがサービスの信頼性と可用性に対する責任を負い、オンコール対応に携わるようになりました。オンコールは重要な職務ですが、精神的な負荷が大きいため不安を感じる方も多く、いわゆる「燃え尽き症候群」に陥る方も生じます。 そこで今回は、PagerDutyコミュニティのメンバーから寄せられた、オンコール対応の不安を取り除く方法や、オンコールローテーションに臨む際のアドバイスをご紹介します。ぜひ、今後の参考にしてください！ インシデント管理における「オンコール対応の重要性」オンコールとは、勤務時間外を含めて緊急対応が必要なインシデントに対応できるように、対応者や担当時間を決めておく仕組みです。 現在は、24時間365日稼働が前提となるシステムが多いなか、サービスの信頼性を守るには迅速なインシデント対応が求められます。仮にサービスが停止することになれば、機会喪失や顧
障害対応で大切だと感じていることのまとめ - Qiita
私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは
限られた人数で 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としてサイト信頼性だけでなく、企画や事業開発な
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
サーバダウンしたニコニコ漫画に何が起きていたのか - BOOK☆WALKER inside
こんにちは。メディアサービス開発部Webアプリケーション開発課の奥川です。ニコニコ漫画のバックエンド開発を担当しています。 2021年初頭、ニコニコ漫画である作品の連載が開始されました。それに端を発する数カ月間のサーバ障害により、ユーザーの皆様には大変ご迷惑をおかけしました。 少し前の話にはなりますが、当時ニコニコ漫画のサーバでは何が起こっていたのか、どのような対応を行ったのかを振り返ってみたいと思います。 1号棟（事の起こり） 2021/01/08 問題の作品（以後、「作品I」*1と記述します）の第1話が投稿されます。その過激な内容からSNSなどでは一部で話題になりましたが、まだニコニコ漫画へのアクセスも穏やかなものでした。 2021/01/22 その2週間後、「第2話（前編）」の公開から事件が起こります。 ピークタイム最中の12:22頃から、まずmemcachedがCPU Utiliz
「オンコール対応するエンジニアの睡眠時間を確保せよ」 GMOペパボSREチームの6つの取り組み
サービスの信頼性を守るため、オンコール対応は重要な仕事だ。だが、夜中に何度も呼び出されるような状況ではエンジニアの肉体的、精神的な疲労は計り知れない。Cloud Operator Days Tokyo 2022のセッション「信頼性を落とさず効果的にオンコールを減らす取り組みを目指して エンジニアの睡眠時間を守ろう」では、こうしたオンコール対応におけるエンジニアへの負担を軽減させる取り組みを紹介した。 「常に何らかのアラート情報が流れている」 GMOペパボの渡部龍一氏（技術部プラットフォームグループ）の役割は、GMOペパボの各種サービスの可用性を確保しビジネスの成長に合わせて適切な環境を提供することだ。そのためのさまざまな業務をこなす中で、オンコール対応は悩みの種になっていた。 「私のチームで対応するサービスだけでも100を超えており、平均すると2、3日に1回のペースで何らかのアラートが発生
アイレット、「企業型確定拠出年金制度」を導入～社員の「働き方」を第一に考え、福利厚生をさらに拡充～｜クラウドの活用ならcloudpack
システム・アプリケーションの開発、グラフィック・UI/UX デザイン制作からインフラの構築・運用までをワンストップで提供するアイレット株式会社（本社:東京都港区、代表取締役社長:岩永充正、以下 アイレット）は、社員の生涯設計を応援する福利厚生をより充実させるため、「企業型確定拠出年金制度」を導入し、2022年4月より運用を開始します。 アイレットは、社員の「働き方」を第一に考えた福利厚生を導入しています。今回、各自で「備える」重要性が増している社会情勢を鑑み、アイレットでも社員における老後資金確保のサポートを目的に「企業型確定拠出年金制度」を導入する運びとなりました。アイレットが選任したファイナンシャルプランナー（FP）資格者と面談が出来る福利厚生「ライフ&ファイナンシャル・プランニングサービス」と併せ、社員の生涯設計を会社がサポートしていきます。 ■「企業型確定拠出年金（DC）制度」につ
開発メンバーの保守運用スキルを上げるため実施している朝当番制度の紹介 - Classi開発者ブログ
こんにちは、開発支援部基盤インフラチームの kenryooo です。 Classiでは過去の高負荷によるアクセス障害での反省を踏まえ、エンジニア向けに保守運用スキルを高める施策として、朝当番という制度を運用しています。今回はその紹介をします。 目的 朝当番制度は、下記を目的に運用しています。 Classiのピークタイム(毎朝8:00 - 9:30)に問題が起きた場合、社内向けにスムーズな情報連携を行う サービス品質の継続的な改善 パフォーマンスや監視内容に異常があった場合や、依存している外部接続システムやSaaSのメンテナンス情報などを担当チームへ共有する 担当エンジニアの育成 Classiシステムの全体像の理解 担当外のアプリケーション(リポジトリ)の理解 システム監視の入門(Datadog) インシデントハンドリングの入門 背景と課題 朝当番制度は、下記の背景と課題感からスタートしてい
単純作業は創意工夫の小宇宙｜shinshinohara
ストッキングの袋詰めを内職に出すことに。まずは一箱どのくらい手間がかかるか調べなくては。両親二人で三時間。ということは、一人だと一箱六時間かかる。それを参考に、一箱あたりの内職代を決めた。案の定、慣れてきた人でも四時間を切ることはできなかった。ところが。 一人だけ、１時間程で一箱仕上げてくる人がいた。そのことを他の内職の人に言うと、皆、信じられない、友達に手伝ってもらっているに違いない、という。 ところがとうとうその人は１時間を切って持ってくるように。本人に聞くと、一人でやってるという。一度、目の前でやってみてほしいと頼んだ。 「うちのテーブルと少しすべりが違うけど」と言いながら、袋の束ををトントンとテーブルの上で叩くと、前に放り投げた。マジシャンのトランプのように、均等に袋がズレて並んだ。まずこれにビックリ。すると今度はストッキングを雑然と山にした。「きちんと並べなくていいんですか？」と
「全員品質」を実現するためのメルペイにおけるDevOpsの取り組み / Best practices to support quality of service
2021年5月13日に開催された「各社のサービス品質を支えるベストプラクティス-EngineeringTeamPresentation」で発表した資料です。 https://sansan.connpass.com/event/209357/ 「全員品質」を実現するためのメルペイにおけるDevOpsの取り組み
本当にサービスの運用できてますか！？運用監視を学べるAWS Observability Workshopを開催しました！
本当にサービスの運用できてますか！？運用監視を学べるAWS Observability Workshopを開催しました！ 技術本部 サービスリライアビリティグループ（SRG）の柘植（@shotaTsuge）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、サイバーエージェントグループと他複数社向けに特別開催したAWS Observability Workshopの開催レポートになります。本記事を通して、運用とは何なのかを改めて考えるきっかけとなれば幸いです。 Day1 Day1では、「サービスを動かし続けるために何が必要か」というタイトルで、 運用とは何なのか Amazonでの運用例 AWS環境では、どのように運用す
なぜなぜ先生がIT企業の分析を赤字添削、「後ろから読み返して」
NTT主要会社のシステム開発や運用を手がけるNTTコムウェアの東日本支店は2015年度から、ヒューマンエラーに起因するミスやトラブルを撲滅するため、再発防止策の立案に「なぜなぜ分析」を活用している。 なぜなぜ分析とは、起こったトラブルの事象に対して「なぜ？」を繰り返し、原因を追究しながら的確な再発防止策を導き出す手法のことである。 同支店では以前から、ヒューマンエラーの撲滅に向けて、TQC（全社的な品質管理）活動に取り組んできた。そのなかにはなぜなぜ分析も手法の1つに含まれていたという。しかし、「TQCは品質管理のフレームワークを記述したもの。具体的な対策に落とし込むのに苦労していた」。東日本支店でなぜなぜ分析を推進する黒澤俊サービス部長兼務エンジニアリングソリューション部長はこう語る。 東日本支店はトラブルの原因を論理的に分析し、未然に防止することを目標に掲げ、なぜなぜ分析を学び直すこと
運用型広告の新規施策の提案で大切にしている3つのこと
運用型広告 注目記事Pick Up：2024年2月によく読まれた記事をまとめて紹介- 2024年3月28日 フェディバースとは？スレッズを中心としたソーシャル連合体は実現するか- 2024年3月22日 Microsoft 広告 アカウントマネージャーに聞く第17回：Microsoft 広告、PMAX がすべての市場で提供開始（3月アップデート）- 2024年3月22日 Criteo、インティメート・マージャーの共通IDソリューション「IM-UID」と連携- 2024年3月22日 Googleの決算書をわかりやすく解説：2023年4Q 過去最高売上を記録！ 知っておくべきポイントは？- 2024年3月1日 新規施策の提案の難しさ 広告代理店勤務時代、今頃が最も忙しかったと思う。日々の運用に加えて、4月以降の提案が大小関わらず毎週のようにあった。今でもそうだが、新規施策の提案を通すことは難しい
なぜ「システムが無事に動いている」ことの価値は理解されないのか
最近はあまり技術的な仕事をしていないんですが、実は私は元々DBエンジニアです。 OがつくDBとか、PがつくDBとか、mがつくDBとかをいじくって、クエリを書いたり、テーブルの設計をしたり、パフォーマンスのボトルネックをあれこれ調べて解消したり、INDEXヒントを総とっかえして頑迷なオプティマイザをぶん殴ったりすることが主なお仕事でした。今でもたまーにそういうことをします。 同業の方であればお分かりかと思うんですが、DBのパフォーマンスは凄く唐突に、かつ多くの場合極端に落ちます。そして、DBのパフォーマンスが落ちると物凄く広範囲に影響が及びます。 アプリケーションサーバ、重くなります。クライアント、ろくに動かなくなります。お客様、切れます。カスタマーサポートにはわんさか電話がかかってきます。 ただ「遅くなる」だけでも十分に影響は甚大なのですが、それ以上のトラブルが発生するとまあエラいこっちゃ
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/coffee_nomimasu/status/1768648873042685986?s=43&t=soNcT6O2AeVewuhHm1Gciw
運用自動化、不都合な真実 // Speaker Deck
Av-jyo.com