慣れているからって、アプリやサーバの設定をいきなり設定しちゃうのはイクナイ。
以下のことを考えてほしい。
・設定コマンド、手順を間違えない自信がある?
・本当にそのコマンドで大丈夫?
・引数が違ってない?
・サービス本当にとまらない?
・なんかあったら元に戻せる?
・で、どうなったら、作業成功なの?
定常業務以外の作業も、事前に手順・コマンド・想定結果は洗い出しておくべきでしょ。
サービス稼動している場合はとくに。
慣れているからって、アプリやサーバの設定をいきなり設定しちゃうのはイクナイ。
以下のことを考えてほしい。
・設定コマンド、手順を間違えない自信がある?
・本当にそのコマンドで大丈夫?
・引数が違ってない?
・サービス本当にとまらない?
・なんかあったら元に戻せる?
・で、どうなったら、作業成功なの?
定常業務以外の作業も、事前に手順・コマンド・想定結果は洗い出しておくべきでしょ。
サービス稼動している場合はとくに。
現在まで、参加したセミナーのメモを整理して[event]カテゴリーに追加中。
最も古いので10年前、一度も整理していので自分のメモが読めない。日本語よりもアラビア文字に近い。また、半数近くが記憶だけでメモや資料が残っていない。思い出す限り追加していく予定。
開催された年月日を書いていないものが大半。ネットで検索してもヒットしないセミナーもあり、
整理に悩むところ。
10年前のメモは要点を抑えられない幼稚な文章。歳を重ねる毎に要点を抑えられてきているように感じる。ただ、メモがマインドマップ的になってきて、こうしてBlogに掲載するには適していない。
9年前の参加履歴を見ていて驚いた。
○1998年07月19日 ◆第1回関東ウェブマスターオフ
○1998年07月25日 ◆関西ウエブマスターオフ
東京、大阪、金沢と1週間で移動している。この頃が一番活発に活動していた。「よくお金があったなぁ」と関心。
「関東ウェブマスターオフ」が当時19才の私には衝撃的だった。
メモの中にキノトロープの生田昌弘さんの発言に
「自分の作成したWebで売り上げが伸びるか結果が分からない仕事はしない」
という発言がある。単にHP作って商売しているだけじゃダメ。結果に結びついてそれ見える形にならないとダメ。
これだけ、IT技術が急速に進歩する中で、この当時、発言されていた方々(生田昌弘さん、佐々木博さん、神田敏晶さん達)の言葉は陳腐化することなく今でも十分通用するのは驚きである。
管理しているサーバの中で3台だけ他部署から引き取ったものがある。
Apacheの設定、アプリの設定ファイルの配置、cronで動かしているシェルの内容。
同じアプリケーションを動かし、使い方も一緒といえども構築した人によって微妙にちがう。
ちがうというか、理解できない。
このサーバ、アプリケーションにログインするとき、個人認証を行っているのだが、
認証サーバの指定先が192.168.xx.xxxとダミー値。Apacheのバーチャルホスト名もダミー値。
なぜ動くの??
1回、OS再起動してみたのだが、何事もなかったかのように動く。
へー、他に設定できる個所があるのか~と思っていろいろ探してみたり、
アプリケーションの開発元のSEさんを捕まえて診てもらうが、
「他に設定するところはない」「ありえない状態」と言われお手上げ。
次回、設定変更するときには楽しいことになりそう。
(3/6追記)
サーバルームの停電で、電源を落として上げたら、予想通り動かなくなって大変な目に・・・。
適当な運用会社・担当者って本当に適当だなぁ。
間違っても、いくら忙しくても、こんな適当な仕事はしたくないなぁ。
定常的な更新作業はたいがいツール化している。
ツール化すると、「だれでも簡単に、間違いなく」できる。このメリットは大きい。
でも、デメリットもある。
たとえば、仕事で1週間に1回(私の隣の人が)実施しているデータの更新作業がある。
簡易ツール化されていて作業手順書もあるが、なんの処理をなんのために
実施しているのか、やらないとどんな問題があるのかを誰も把握していない。
エラーが発生した場合なんて対応できない。
いつもバックアップからデータを戻し、1から手順のやり直し。
それでもダメな場合は・・・お手あげ。
運用ツールを引き継ぎを受けるときは、処理目的・内容・ロジック、
エラー時の対応方法を把握し、ツールのソースを見ておくべき。
ソースが理解できない運用ツールは、うけとっちゃいけいないでしょ。