ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
「運用組織」の考え方と設計 〜 運用組織論 2021 / 20210310-ssmjp-operation-organization
ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい
前にも似たようなこと書いたなと思ったけどもう一年半も前のことになるのか t-cyrill.hatenablog.jp ご存知の通り昨日 2021/02/19 23:20頃 AWSにて東京リージョンの一つ apne-az1 にて大規模な障害が発生。多くのAWSを利用していたサービスで影響があった。 そんな私はいつものように アラストリリィ アサルトリリィ ラストバレット というゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。 どうしたんだろうと思っていたら、社内SlackにてAWSを利用しているサービスがたまに応答しなくなる、Elasticacheが切り替わったなどなどの報告が入り、もしかすると面倒ごとかなと思いながら対応することになった。 起きていたこと 既にAWSからも公開されていることであるが、今回は2019年8月に起きた障害と類似するタイプの障害だっ
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
コンテナを利用したWebサービス開発と実運用
はてな×さくらが考えるテクノロジーの未来〜コンテナ・分散型データセンター〜 Mar 20th, 2019 Profile id: Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU はてな東京オフィス チーフエンジニア Mackerel プロダクトマネージャー 60+ CPAN Modules 3 Times ISUCON Winner Using Perl YAPC::Tokyo 2019 ベストスピーカー 最近はGoが好き
ElastiCache for Redis 運用小話 〜メドレー・ TechLunch〜 | MEDLEY Developer Portal
2018-05-25ElastiCache for Redis 運用小話 〜メドレー・ TechLunch〜こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等にElastiCache for Redisを利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様についてキャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction
Redis 本番障害から学んだコードレビューの勘所
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩
次世代Webカンファレンス「モニタリング」レポート #nextwebconf | DevelopersIO
こんにちは、虎塚です。 10月18日(日)、次世代 Web カンファレンスへ行ってきました。イベントの趣旨は「「次世代 Web カンファレンス」を開催します - Block Rockin’ Codes」で公開されています。 最後のセッション「monitoring」に参加したので、レポートします。 オーナー: @songmuさん はてなで監視サービスのMackerelを作っている @mikedaさん クックパッド株式会社のインフラ監視をしている @rrreeeyyyさん ハートビーツ-でMSPをしている（サーバを預かって監視、構築など） @fujiwaraさん インフラや監視まわりのお仕事をしている 監視とは何か mikedaさん：監視とは、サービスが正常に稼動しているかをみて、異常を検知したら収束させるという活動を含むもの。 fujiwaraさん：落ちたら困るので監視する。将来リソースが足
unicorn-worker-killerが便利だった件 · zephiransasのチラシの裏
自分が現在関わっているプロジェクトでは、nginx + unicornの構成で運用しているのですが、この構成でサーバのメモリが足りなくなるという現象に悩まされていました。 unicornのワーカプロセスは、通常では起動したままユーザからのリクエストを処理し、再起動されることはありません。 その関係で、長時間運用していると、そのワーカプロセスがメモリをあるだけ食いつぶすような挙動になります。 こんな時に便利なのが「unicorn-worker-killer」です。 unicorn-worker-killerを使うことで、ワーカプロセスが以下の条件の場合に、自動的に再起動してくれます。 ワーカプロセスが指定回数のリクエストを処理した場合 ワーカプロセスが指定量のメモリを使用している場合 いずれの場合でもワーカプロセスの再起動は、現在のリクエストを処理した後に再起動（いわゆるgraceful r
ライブラリの利用を減らしていくことの重要性 - ボクココ
ども、@kimihom です。 最近の運用フェーズでの開発で意識していることの一つ、「Gem ライブラリの利用を減らす」ことについて思うことを書く。 記事の内容は Ruby 周りに最適化されているけど、他の言語でも同様のことが言えると思うので適宜置き換えて読んでいただきたい。 初期フェーズによるライブラリの利用 新サービスを作る段階では、「いかに早く機能を作り、検証しながら機能を作り直していくか」が大事になってくる。その時にいちいち機能をゼロから自分で作っているようでは時間の無駄だ。第三者が作ってくれた、ライセンス的に問題ないライブラリをシステムに組み込み、作っては壊しての繰り返しで機能検証していくことが大事になってくる。サービス開発初期でライブラリを使う理由は「機能を素早く実現するため」にある。だからちょっとした機能でも Gem で入れまくることになる。 これは全く問題ない。むしろ推奨さ
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか？ まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
＠ITイベントカレンダー
平素よりイベントカレンダー＋ログをご利用いただき、誠にありがとうございます。 イベントカレンダー＋ログは「IT・製造業・ビジネス関係のイベント（セミナー・展示会・勉強会・コンテスト・Webイベントなど）を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー＋ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年6月30日（火）15:00をもちましてイベントカレンダー＋ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
ログアウトしてもバックグラウンド ジョブを継続する方法
はじめに SSH 接続で時間の掛かるシェルスクリプトをバックグラウンドで走らせて帰りたいのに、SSH 接続を切るとジョブが死んでしまいます。SSH 接続に限らず目の前の OS からログアウトしたりターミナル エミュレータを終了しても同じ現象が起こります。 この症状は正常です。なぜなら、バックグラウンド ジョブを起動したプロセス(ログイン シェル)が子プロセスである該当のバックグラウンドジョブをハングアップ シグナル( HUP )によって終了させるからです。 シェルスクリプトを起動した親プロセスは子プロセスの終了状態を監視しています。ですからログアウトして親プロセスであるシェルが終了すると子プロセスはゾンビ プロセスとなってしまうので親プロセスとなるシェル(ログインシェル)は子プロセスであるバックグラウンド ジョブを kill ( kill -HUP ) するのです。 nohup コマンド
Ruby を利用した大規模ウェブサービスの開発・運用 - RubyKaigi 2011 発表資料 - クックパッド開発者ブログ
技術部開発基盤グループの id:secondlife こと @hotchpotch こと舘野です。 先日の RubyKaigi 2011 で、「Ruby を利用した大規模ウェブサービスの開発・運用」という内容で発表させていただきました。 前半はクックパッドのサーバアーキテクチャ、各種サーバのアプリがどんな風に動いているのかの紹介を、後半では「開発」→「デプロイ」→「フィードバック」→「開発」…という、サービス開発で行われているサイクルを30人以上エンジニアが居るクックパッドでどう高速に回し続けているかのお話しです。 Ruby を利用した大規模ウェブサービスの開発・運用 [slideshare id=8630511&w=425&h=355&sc=no] View more presentations from hotchpotch 当日のRubyKaigi 2011 での発表の動画は、以下を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Introducing Dispatch
資産運用 - shao's Scrapbox
RDBMS in Action
最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」 - Speaker Deck
クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について // Speaker Deck
