【社内資料公開】AWSトラブルシューティングページまとめ／より早い原因把握のために心がけること | DevelopersIO
はじめに こんにちは植木和樹です。オンプレで10年近くサーバーの保守運用をやっていた経験からいいますと、AWSの障害発生率は非常に低くて驚きます。数百台規模のサーバーを扱ってますと、毎日どこかでのサーバーでディスク、CPUファン、メモリーパリティエラーなんかの故障が起きていて日々対応に駆けまわってた覚えがあります。 さてAWSの障害発生率が低いといってもゼロというわけではありません。仮に0.1%だとしても1000日つまり3年運用していれば1回くらい障害に遭遇するものです。0.01%だったとしてもサーバーが1万台あれば1日1回なにかしらのトラブルに遭遇しても不思議ではありません。 トラブルに遭遇すると、当然サービスや処理に影響をきたしてしまうわけで早期の暫定処置と、その後に恒久的な対策が求められます。その時に重要なのは早く正しく原因を特定することです。トラブルシューティング力が重要です。 A
【Linux小技】 sshやscpをパスワードなしで利用する方法 (複数台サーバ対応スクリプト付) 「知ったかブログ」
今まで、 rootアカウントでrshを利用する方法や、 rootアカウントでtelnetを利用する方法 を紹介しましたが、今回はsshをパスワードなしで利用する方法です。 基本的にはCentOS5やCentOS4や同等のRedHat ELで確認してます(たぶん他のOSでも問題ないと思いますが・・・) sshなので、一般ユーザおよびrootでも使うことができます。 A：2台のサーバ間での設定 まず、基本です。下の図のように、server01、server02の2台が通信できる状態です。 server01、server02ともに同じユーザ名が登録されていることが必要です。(今回はkenユーザです。同じuid、gidにまでする必要はないかもしれません) (図１) +-------+ +--------| NW SW |-----+ | +-------+ | | | +----------+ +
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
