harumaki.net

インフラ屋の覚書や、ラーメン食べある記とか。

infra メモ 運用

インフラ運用の心得:最低限やっておくこと

投稿日:2010年10月15日

Last Updated on 2012年8月16日 by かんりにん

[pukiwiki]

#contents

*インフラ運用に最低限やっておくこと [#m5d8ab99]

以下の整備については、”呼吸するのと同じくらい当たり前のこと”としてやっておくこと。
もちろん必要以上のコストはかけない前提で。
必要と感じたことは都度追記。

**1)ドキュメント作成

”構築時にドキュメントを残さないのは論外”だがめんどくさがらずにしっかりまとめる。
”とにかく書きまくる、と同時に見やすく、判りやすく。”
また購入した製品のドキュメントや保守契約書、保証書などが行方不明、というのはよくあるパターン。
きちんと体系化・ファイリングすること。紙媒体のものはPDFなどに落としておいても良し。

その一方で、なんでも残しておくと、どんどん増えていくものなので、
アップデートと廃棄をしやすくする前提で常に整理整頓してすっきりさせとく。

あと、自社内利用かお客さまへの納品物かは問わず、”見た目は大事”。
-キレイにすっきりまとまるよう、気を配る。
-ベンダーさんから納品されたドキュメントがあれば、をガッツリまねてみる。
たいていテンプレートして使い回しが効くように練られているし、良いと思ったものは
どんどん盗みまくり、ノウハウとして身につけていく。
たまにヘナチョコな納品物もあるけど…
-あるいは先輩社員のドキュメントで、学べるものがあればガンガン盗んでいく。
このへんは基本か。
そして後輩・後任に引き継いで、より良くアップデートしてもらう!

-仕様書
–ネットワーク図
–サーバ仕様書
–アプリケーション仕様書
–DB
—ER図
—CRUD図
–そのほかいろいろ
-各種契約情報
–ハード
—契約書
—サポート期限(ハードウェア、関連ソフト)
–ソフト
—契約書
—サポート期限、あと使用中のバージョンのアップデート期限
-運用マニュアル・作業手順書
-作業ログ
-障害対応時のログ・ナレッジ
-そのほか、いろいろと。

**2)ログ

サーバーはともかく、ネットワーク機器はメモリが少ないうえに
ログはトラブルシュートに欠かせないので、外部にしっかり出力しておく。
キャプ翼風に言うなら、””ログは友達””!

またルーター上でshow logするより、syslogサーバ上でログを閲覧したり
解析用に加工するほうが、ファイル操作コマンドが多くて何かと便利。
あとネットワーク機器上でのファイル操作はビミョーに気が乗らない…
※IOSにはgrepがあるし、それはそれで便利だけど。

-syslogファシリティ
ネットワーク機器はsyslogサーバを用意しておく
-バックアップ
延々とログをとり続けてディスク使用率が肥大、というのもありがちなので
(catalina.outが数十GBとか)
ローテートもきっちり設定(logrotateで一緒にやっちゃっても可)。

**3)バックアップ/データ

これまた大基本。

-バックアップ
–コンフィグ
–コンテンツ
–DBのダンプ
–システムイメージ
-ローテート
–スケジューリング

あとはGitやSubversionを転用(?)してコンフィグのアップデートを管理する、
あるいはpuppetやchefなどでの管理も有効(やや慣れが必要になってくるけど…)。

最後に、バックアップを取得しているだけでは仕事は半分しか完了していない。
すばやく、確実なリストアを実行できる環境まで整備してようやくコンプリートできるといえる
(と、書いているほど立派な仕事ができているわけではないのですが…)

**4)バックアップ/ハード

-ごく基本だけど、購入ないし契約した日から保守サポートが始まっている!
ハードウェアは購入したらすぐに使うこと!
稼働していない期間はコストののムダ、そしてリリースするまでの間もコストを回収できない無駄な期間と言える。

-運用方法はアクティブ/コールドスタンバイでもアクティブ/アクティブでも
フェイルオーバーさせてもなんでもよいが、ダウンタイムを下げるため
導入時はあらかじめ2台用意することを前提とすること。

-”予算の都合は、努力で何とかする”(汗
役員を口説いて予算をゲットするか、金が無いなりになんとかするかは、ま、いろいろとw
ある程度妥協してみたり、ルータやファイアーウォールは
中古のノートPCにLinuxを入れて自作してみたりと、なんとかガンバってみるとか…
g○○gleさんに見習って、マザボベースでホストをガシガシ組み立てていくとかw
ここ1~2年ほどは国内の大手サービスでも組み立てサーバーを増やしている企業さんも
多いようですね。

**5)バックアップ/ネットワーク機器

最近のルーターやファイアーウォール、スイッチは安価なものは
CFに代ってUSBフラッシュやSDカードを利用できるものが多いので、
ファームウェアのアップデート用途だけでなく、バックアップ用にしっかり活用する。
メーカーものでも安価になり、どこでも手に入るから、手を抜かないこと。
(身元不明・品質に疑いのあるバルクは×で)

**6)監視 /トラブルシュート [#t96c21c9]

”トラブル発生時に何が起きたのかわからない、というのは話にならない”ので
つねに状態監視とログ出力を行っておくこと(しつこいけど、ログは友達!)。

最近の監視ツールは大抵のツールがそろっていることが多いが、
詳細な情報を得たいときはスクリプトを自作する場合もあるので
SNMPやソケットから、Web屋ならデバッグやhttpヘッダーなどの知識を深~く学んでおく。

※監視をすることで”不都合な真実”も見えてしまう場合があるが…

**7)ネットワークサービス

ホスト毎のローカル環境としての、ネットワークサービスの設定。
これらも放置になりやすいので、サーバやルータをセットアップした時に
ちゃんと設定しておく。

-NTP
LAN内にグローバルのNTPサーバへ同期をとりに行くLAN用NTPサーバを立てて
他のホストから同期させても良し。
時間管理にシビアである必要が無ければ、リソース節約のため、ntpdateをcronで1日1回実行させる程度でも良し(DBは除く)。
-DNS
リゾルバの指定はセットアップ時に普通にやると思うけど、一応記述しておく。
-メール
–エイリアス定義
Linuxの場合、ツルシのままだとsendmailがデフォルトで自動起動になっており
”cronの失敗メールやlogwatchなど(動いている場合)が、ローカルのスプールに延々と溜まるという、だめパターンになりやすい”ので
最低限以下のエイリアスは転送設定にしておく。
mailer-daemon
postmaster
不要ならsendmailなどのデーモンをとめておく、というのも(考え方によっては)有効。
–転送先
インターネット側にゲートウェイを持たないホストの場合も
ローカルホストにdefferredが延々と溜まる傾向になるので、必要に応じて転送先も設定しておく。

[/pukiwiki]

-infra, メモ, 運用

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA


関連記事

[AWS]EC2インスタンスにS3をマウントしてみる(s3fs)

EC2インスタンスにS3のバケットをファイルシステムとしてマウントし、ファイル転送などを試してみる。 実際に使ってみた感じではmountコマンドと同様に利用でき、扱いやすそう。 -参考ページ:お世話に …

no image

monitインストール[RHEL3]

[pukiwiki]   システムマネージメントツールmonitのインストール 監視ツールの発展版といえる、デーモン監視と異常時の再起動などを行う便利ツール。 既にnagiosやzabbixをインスト …

no image

[MySQL] ZRM(Zmanda Recovery Manager) コマンドをいろいろ

“Zmanda Recovery Manager / ZRM”のRPM版にて一緒にインストールされるコマンドをいろいろ探ってみたので、メモをいろいろと。 ▼参考:お世話になって …

nagiosgraph​/メモ:nagiosグラフで出力されるレポートについて

  [pukiwiki] *nagiosグラフで出力されるレポートについて [#xda76c69] nagiosgraphをセットアップした時気になったことをツラツラと。 **1)自動で出力されるグラ …

no image

[Juniper]SRX アカウント設定いろいろ

SRXシリーズでのアカウントの各種設定をメモ書き。 コマンドラインから操作する場合は、原則configureモードで行う。 参考:お世話になっております! SRX Getting Started &# …