たくさんのホストにpingするのに便利なツールpingerを書きました - （ひ）メモ
たくさんのホストにpingするのに便利なツールpingerをgoで書きました。 https://github.com/hirose31/pinger こちらから Linux, macOS, Windows 用のバイナリがダウンロードできるので是非お試しください。（手元に環境がないのでWindowsでは動作確認していません） https://github.com/hirose31/pinger/releases メンテナンス時、特にネットワーク関連のメンテには、多数のホストへの到達性をモニタリングしがら作業したいことがあると思いますが、（自分が知ってる限りの）既存のツールでは一覧性がよいものがなかったのがこのpingerを書いた動機です。 pingerを実行すると、このように上部には指定したホストの状況を2カラムで表示し、下部に失敗したホストの履歴を表示するので、現在の状況（上部）と過去の状
Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認（w） サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認（df） 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
マニュアルオペレーションするとき気を付けたいこといくつか - ふり返る暇なんて無いね
少し思うところがあったのでメモ。 ほぼ自己流なので、もっと良いのがあれば教えて欲しいところ。 そもそもマニュアルオペレーション(手作業)するな ごもっとも。でもやらないといけない深淵な事情があるんです。 事前条件と事後条件を明確にしておく どういう状態からどういう状態に変わるべきか事前に明確にしておくべきです。 それなしに普通は作業しません。 切り戻し手順を考えておく 途中でミスる可能性があるポイントを明確にしておくこと。 それぞれのタイミングでの切り戻し手順をしっかり考えておくこと 作業手順を事前に書く オペレーション中にアドホックに手順考えないですよね? 複数手順あるならスクリプト化する できる限りステップを減らします。可能ならスクリプトを一発叩くだけにします。 set -eu は付けた方がいい eオプションはコマンドのステータスコードが0以外(異常終了)したときに、その時点で終了して
溜まるジョブキュー - ふり返る暇なんて無いね
ジョブキューのジョブが溜まる理由として以下のものが考えられる 単位時間当たりでのジョブをキューイングする量が多い ジョブ自体の実行時間が長い 片方の条件が成り立つ場合も両方とも成り立つこともあり得る。 高負荷時には両立することが多いだろう。 解決策としては以下のものが考えられるだろう。 キューイングする量を減らす ジョブの実行時間を減らす ジョブのタイムアウトを設定する ワーカーの数を増やす (キューをクリアする 最終手段) キューイングする量を減らすのは単純だけど効果ある。不必要な場所でジョブに投げてないか見直すと良い。だが、肝心のジョブ自体の実行時間が長ければ、減らしても結局たまり続ける。 内部処理にとどまるのであれば、ジョブのチューニングやワーカーの数を増やすことで何とかなる場合もあるが、ジョブ内で外部APIを叩いている時などはそうはいかない場合もある。外部要因が絡むときは敢えて一定
エンジニアでもターミナル作業ログを残したい!! - 目の前に僕らの道がある
今まで下記のようにexecで標準出力と標準エラー出力を作業ログに残すという事をしてたんですが、実際に打ったコマンドは出力されないので、ちょっと不便だなーと思ってました。 exec > >(tee --append /tmp/$(date +"%Y.%m.%d")_$(id --user).work.log) 2>&1 ちょっと調べて見るとscriptコマンドを使うとコマンドを含めて出力できることを知りました。 これで作業ログを残すのがはかどる! script --append --flush /tmp/$(date +"%Y.%m.%d")_$(id --user).work.log チームメンバーにこのログをtailさせておけば、画面共有も出来たりもします。 (その用途ならホントはwemuxとか使った方が良いんでしょうけどね。。 tail -F /tmp/$(date +"%Y.%m.%
運用担当者、激減中
ユーザー企業の情報システム部門で今、運用担当者の人数が大きく減り始めていることをご存じだろうか。 運用業務には、「アプリケーション保守」や「OS/ミドルウエア運用」、「ITインフラ運用」などがあるが、あらゆる業務に関わる運用担当者が減少しているのだ。まずは4社の事例を紹介しよう。 サイバーエージェント 運用担当者の人数 20人→0人（予定） サイバーエージェントで消費者向けWebサービスを手がけるアメーバ事業本部では、現時点で20人いるOS/ミドルウエアの運用担当者を、2年後の2015年までにゼロにする計画だ。 彼らは現在、OS/ミドルウエアをサーバーにインストールしたり、パッチを適用したり、アプリケーションの負荷に応じてサーバー台数を増減したりする業務を行っている。これらの業務を、オープンソースソフトウエアの運用管理ツール「Chef」を導入することで、自動化する計画だ（図1）。
構築済みサーバを RSpec でテストする serverspec という gem をつくった - Gosuke Miyashita
Puppet や Chef で構築したサーバを RSpec でテストする で書いた仕組みを使いやすくするために serverspec という名前で gem 化してみた。 rubygems.org にも登録してあるので、gem install でインストールできる。 $ gem install serverspec インストールしたら、適当なディレクトリで serverspec-init を実行。すると、雛形となるディレクトリやファイルを生成する。 $ serverspec-init + spec/ + spec/www.example.jp/ + spec/www.example.jp/httpd_spec.rb + spec/spec_helper.rb + Rakefile spec/www.example.jp/httpd_spec.rb がサンプルテストコードで、こんな感じになって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
宁波逼拘旅行社