PagerDutyを導入して障害対応の体制と運用ルールを確立しました - LCL Engineers' Blog
Webエンジニアの古賀です。LCLでは、障害対応の強化の一つとして多機能な通知機能を持つPagerDutyを導入しました。 組織的な対応シフト・フローが組めるようになり、精神的にとても安心できるようになったので紹介させていただきます。 pagerduty.digitalstacks.net 導入前の課題 LCLでは、Mackerelを利用して各サーバの監視しており、障害が発生するとチャットでエンジニアへTO(メンション）で通知をしていました。 この運用方法では、以下のような問題がありました。 全エンジニアへの通知のため、早めに気づくエンジニアが固定の担当になりがち TO（メンション）の重要度が高く、通常のやりとりで使いづらい 通知は一度しかこないため、他のチャットで埋もれてしまい見逃す可能性がある チャットでの障害通知では限界が見えてきて、何かいいサービスはないか検討していたところPage
Mackerelのアラートグループを利用して障害通知を抑制する - LCL Engineers' Blog
Webエンジニアの森脇です。現在、障害通知の最適化を進めており、その第一弾としてMackerelのアラートグループ機能を利用して、障害通知の抑制をしました。手軽に実現ができ、便利だったので紹介します。 当初の課題 LCLでは、Mackerelを利用して各サーバのメトリクス監視やサービスの外形監視をしています。アラートが発生するとチャットへ通知していますが、大規模な障害発生した場合は、以下のようにアラート通知でチャットが埋まってしまっていました。 チャットがアラート通知で埋まってしまうことにより、障害対応の妨げになる問題が多く発生していました。 障害対応のやりとりをしても、アラート通知ですぐに流れてしまう 大量の通知がノイズとなり、障害対応への集中を削がれる OK/NGのアラートが個別に通知され、すべてOK状態になったかチャット上で判断しづらい すぐに解決策が見つからず放置になっていましたが
PostgreSQLでWebサービスを運用するためにやっていること - LCL 開発者ブログ
弊社では、RDBMSにPostgreSQLを利用して数年間サービスを運営しています。 PostgreSQLはMySQLと違って、Webサービスでの運用事例をあまり見かけないので、今回は弊社サービスの「夜行バス比較なび 」でどのように運用しているかを紹介いたします。 システムの特徴 ユーザからのアクセスは、9割が参照処理。 データはバッチ処理で、随時 ( 毎分 ) 更新されている。 参照SQLの結果はmemcachedを利用してキャッシュをしているが、データの更新頻度が高いため長時間のキャッシュはしていない。 参照SQLは、集計処理が多いため比較的重いSQL。 参照対象となるテーブルのデータ量は、最大で数100万レコードと比較的少ない。 24/7で稼働。 構成 AWSのEC2上に、PostgreSQL 9.3を導入しています。c4系のインスタンスを使いたいので、RDSは使っていません。インス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
