[書籍レポート] 「オブザーバビリティ・エンジニアリング」はパワーワード満載の「『入門 監視』の次に読むべき本」だった | DevelopersIO
自分の関わるアプリケーションやインフラのモニタリングに困っている？ オーケイ、冒頭からアクセル全開の力強いワードにあふれたこの一冊を紹介するぜ！ はじめに 今年(2023年)の1月末に発売されたこちらの本、もう読まれたという方も多いのではないでしょうか！（挨拶 本記事は、まだ読まれていない、買ってもいないという方に向けて、「紹介しなきゃ」という謎の強い使命感をもって書かれています。 というのも、実は本記事の執筆者（ぼくです）は、300ページを越えるこの本のまだ半分ほどしか読むことが出来ていません。。！ *1 それでもこの本を紹介するモチベーションは十分です。なにしろ、この本は冒頭から、もっといえば「まえがき」の段階から、パワーワードにあふれた一冊だからです。引用してみましょう。 “（「オブザーバビリティ」という）用語が注目されるようになると、ある種の隣接性を共有する別の用語と互換的に使われ
![[書籍レポート] 「オブザーバビリティ・エンジニアリング」はパワーワード満載の「『入門 監視』の次に読むべき本」だった | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e557ded8e0ecef2f687c73d647f86e0ce3cffd0b/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F02%2F202302-report-observability-engineering-eyecatch.jpg)
資料公開 Ops JAWS Meetup#21 に「システム運用アンチパターン のすすめ」というタイトルで登壇しました #OpsJAWS | DevelopersIO
資料公開 Ops JAWS Meetup#21 に「システム運用アンチパターン のすすめ」というタイトルで登壇しました #OpsJAWS こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 2022年6月21日開催 Ops JAWS Meetup#21 に「システム運用アンチパターン のすすめ」というタイトルで登壇しました。 その際に投影した資料を公開します。 資料 サマリー CAMS Culture (文化) Automation (自動化) Metrics (メトリクス) Share (共有) 承認の自動化 ゲートキーパーとの摩擦を避け、承認を本来の目的に戻すためには自動化が有効です。 承認の自動化をするとしても承認自体の目的は果たすようにしましょう。 運用の自動化 自動化による改善を行いましょう 自動
テクニカルサポートを最大限活かすための問い合わせ文の作り方 | DevelopersIO
この記事はアノテーション株式会社 AWS Technical Support Advent Calendar 2021のカレンダー | Advent Calendar 2021 - Qiita 19日目の記事です。 気付けば4年間テクニカルサポートをしていました アノテーション・テクニカルサポートチームの m.hayakawa です。 元々はソフトウェア開発エンジニアでしたが、ひょんなことからテクニカルサポートの業務を始めて 4 年以上、様々な問い合わせ文と向き合ってきました。 せっかくなので今回は 4 年間の仕事の中で身に着けた暗黙知を「テクニカルサポートへ問い合わせを行う際の文章作成」という題材にて、ブログ化していきたいと思います。 テクニカルサポートだけでなく、一般的な「カスタマーサポート」に関連するような、なるべく平易な内容を心がけます。 これを実践することで、テクニカルサポート側
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
障害発生！全員集合？ － オンコールアンチパターンからの一歩前進 - Cybozu Inside Out | サイボウズエンジニアのブログ
8月だというのに涼しい日が続きますね。 kintone.comのDevOpsをしている@ueokandeです。 もうすぐAWS版kintoneのローンチからから2年が経過しようとしています。 この2年間、DevOpsチームではkintone.comのサービス安定化やスケーラビリティに注力してきました。 時には本番環境の障害で休日や深夜に障害対応することもあります。 kintone.comの障害の一次対応は、我々DevOpsメンバーが実施しています。 サービスローンチ直後は、メンバーの多くがオンコールに不慣れで、慌てて障害対応したりうまく進められないことが何度もありました。 そこでメンバー全員が効率的・効果的な障害対応を目指すべく、チームでPagerDuty社のIncident Response（非公式日本語訳版）を読むことにしました。 この記事ではAWS版kintoneで実際に体験した障害
SLO策定とアラート設定までの長い道のり - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、@ueokandeです。早速ですが、皆さんが運用しているサービスには、SLO (Service-level objective: サービスレベル目標) がありますか？アラートの監視項目はどのように設定して、基準値をどのように決めていますか？ 社外とのコミュニケーションだけでなく、社内向けのSLOを決めておくことで、サービスの健康状態を知るための手がかりや、普段の開発・運用タスクの優先度を決める上での指標にもなります。 またSLOがあると、サービスを監視するアラートに、理にかなった閾値を設定できます。 この記事ではAWS版kintoneの、SLOとアラートを設定するまでの記録について紹介します。 cybozu.com版kintoneのSLOとアラート 国内のcybozu.comで運用しているkintoneにも、もちろんSLOやアラートはあります。 しかし現状のSLOはkinton
バッチプログラムの運用と監視について検討しよう | メルカリエンジニアリング
こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemu です。 バッチプログラムのお話、今回は運用・監視についてお話したいと思います。当社はすべての業務が24時間行われていますので、システムがオンラインのときに動作するバッチプログラムについてのみ議論します。 過去の記事はこちらにあります。 運用に備えて バッチプログラムの運用について、「プリモーテム」「実行管理」そして「ログ管理」の3点について述べていきます。 プリモーテム ポストモーテムという言葉を聞いたことがある方はいらっしゃるかと思います。ポストモーテムとは、GoogleのSRE本の15章*1によれば、障害などの失敗を振り返り、今後に活かすプロセスの総称と捉えることができます。 さて、プリモーテム(プリモータム)とは何でしょうか。この言葉は、私が最近読んだThe Manager’s Path*2*3で使
保険契約・保険請求のスマートコントラクト化を進めるInmediate、日本市場に進出へ——三井住友海上や新興保険会社FWDらとPoC運用で協業も - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
損害保険ビジネスを効率化する過程では、被保険者とのタッチポイントにおけるコストをいかに圧縮するかが一つのテーマだ。損害保険会社にとって被保険者とのタッチポイントは、契約時と事故発生時の保険請求の2つ。このうち、前者の「契約時のタッチポイント」については、従来の保険外交員や代理店を通じた保険契約に代え、オンラインや電話契約などにより効率化されるようになった。残る「保険請求時のタッチポイント」をいかに効率化するかは、損害保険会社においては技術進化が期待されるフロンティアと言えるだろう。 Inmediate は、まさにこのテーマに一石を投じようとしているブロックチェーンスタートアップで、シンガポールを拠点にスマートコントラクトの技術を元にした保険引受・保険請求のしくみを開発している。保険引受・保険請求に関わる80％程度の契約事務手続を自動化し、ブロックチェーンを使っていることから、より透明性の高
GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
DockerをWebブラウザで管理できる「Seagull」レビュー | さくらのナレッジ
Dockerを本格的に使い始めると、どのコンテナが動いていて、イメージは何があるのかなどの管理が煩雑になります。ターミナルで操作はできるものの、実際に運用を行っていく中ではやはり管理用のインタフェースが欲しくなるのではないでしょうか。 そこで使ってみて欲しいのがSeagullです。コンテナやイメージの状態を一覧表示したり、起動や停止と言った操作もできるDocker管理用のWebシステムとなっています。 今回はこのSeagullをさくらのクラウドを使って試してみました。 用意するもの Ubuntu 14.04 LTS（CentOSやCoreOSでも動くと思いますが） Docker（apt-get install docker.io） Seagullのインストール SeagullのインストールはDockerコマンドでできます。 $ docker run -d -p 10086:10086 -v
バッチ処理について再考 - プログラマでありたい
作業途中のメモです。バッチ処理の定義を確認しようとしてWikipediaをはじめとして幾つかのサイトをみてました。その時に目に入ったのが、下記の文章です。 利点 バッチ処理には以下のような利点がある。 ・多くのユーザーがコンピュータのリソースを共有できる。 ・処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 ・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 ・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。バッチ処理 - Wikipedia これだけみると、人件費に対してコンピュータリソースが高い時代の産物なんですよね。今は、クラウドの登場で、有り余るコンピュータリソースをほぼ自由に低コストに使える時代です。そもそもバッチ処理である必要があるか、考える必要がありますね。特に夜間バッチにつ
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
「チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化」の資料のリンク - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
これからAWSを始める人は一読すべき「AWS運用チェックリスト」を読んでみた | DevelopersIO
はじめに こんにちは植木和樹です。AWSでは各種ホワイトペーパーなどの資料を多数公開しています。 AWS アーキテクチャーセンター | アマゾン ウェブ サービス（AWS 日本語） 今回は上記ページからダウンロードできる「AWS 運用チェックリスト（PDFファイル）」を読んでみました。運用チェックリストという名前ではありますが、AWSを利用する方は一度目を通しておくのをお勧めする内容でした。 チェックリストは大きく3つ「ベーシック」「エンタープライズ」「セキュリティ監査」に分かれています。このうちベーシックは15項目程とコンパクトにまとまっていて、簡易チェックリストとしてお手頃です。 残念ながらまだ日本語訳がされていないようですので、今回ベーシック部分だけをザックリ読んで簡単なコメントを書いてみました。 ベーシック運用チェックリスト 原文は「我々は〜〜〜を設定しています（理解しています）」
事故らないために普段守っているターミナルの運用ポリシ（Mac + iTerm2）｜TechRacho by BPS株式会社
morimorihogeです．新年一発目の投稿です．最近木曾が改二になりました． Web開発に限らず，UNIX系で動作するシステムの開発・運用に携わっていると常にターミナルクライアントを開いているということが多いかと思います．Web開発やサーバインフラの構築・運用をやっていると，自分のローカルPCだけではなく，リモート上の別マシンに接続し，テストサーバや本番サーバでコマンドを打って作業する機会が多くなります． そんな中「ローカルマシンのコンソールだと思ってrmしたら実は本番系サーバだった」「なんか色々実行してて処理が怪しいなと思ったら別のサーバだった」という思いをしたことがあるのは僕一人だけじゃないと思います． 今回はこういった問題を防止するために僕が普段から守っているターミナルの運用ポリシを紹介してみようと思います．あまり技術的な話はないですが，普段開発・運用を仕事としてしていく上でのノ
データベースサーバを複数台構成とか2010年代には流行らない - blog.nomadscafe.jp
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
HP「NonStopサーバー」って？／フェイスブックの中の人に聞いたMySQL 5.6の使い方
今月は「止まらない」ことをとことん追求し、OSと一体化して稼働するデータベース「HP NonStop SQL」と、フェイスブックにおけるMySQLの運用について紹介します。 「止まらない」を追求したHPのNonStopサーバー 本連載では、普段はオープンシステムやオープンソースのデータベースを対象に取材していますが、今回のHP「NonStopサーバー」はハードウェア、OS（NonStop OS）、データベース（NonStop SQL）、全てが一体化した独自設計の商用製品です。 金融や通信業界のミッションクリティカルやハイエンドの領域で多くの実績があり、全世界のATMトランザクションの70％、クレジットカードトランザクションの3分の2はNonStopサーバーが処理しているといわれています。 日本ヒューレットパッカード プリセールス統括本部サーバー技術本部 山本呈氏と原敏光氏が解説してくれまし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shiodaifuku.io
40まで開発のリーダーだった男がインフラの運用のリーダー(見習い)になってみて
http://paperboy-all.github.io/docs/nagios/learning.html
