管理人のお仕事体験記シリーズ。
今回は検証環境の維持管理のあるあるとその対処について。
維持管理は地味でトラブルが起きない際は評価がされず、トラブルが起きた際は、やれ早く直せだの、どうして壊れるんだなどやり玉に挙げられますが、非常に重要なお仕事だと思ってます。
検証環境をメンテしたことありますか？
管理人は情報系の研究開発でご飯を食べています。
昨今の開発だと、AWSなど仮想化環境上に開発・検証用の環境を用意する場合もありますが、クリティカルなシステムは依然として自前で構築します。
そのため、企業によっては実験室に複数のサーバ・スイッチを配置してそれらを常にメンテする必要が生じます。
管理人もそのメンテのお仕事を任されています。
検証環境のメンテとはどんなことをするの？
システムが壊れないように日々お祈りしています。
嘘です。
扱う環境の規模にもよりますが、環境を構成する主な要素であるサーバやスイッチの異常時に、トラブルを解決する役割を担います。
場合によっては、空調や電源も見ますが基本的には管理人はサーバとスイッチを対象としてます。
ここからは会社による部分もあると思いますが、サーバ・スイッチを見るといってもそのうえで動作してしているアプリまで範囲にするかそれともOSレベルまでにとどめるかで話が変わってきます。
管理人はOSレベルまでを対象とする管理なので、アプリレベルの異常と切り分けられれば、あとはアプリ担当に任せるという運用をしています。
個人的にはこの役割分担が適切だと考えています。
OSレベルであれば、多くのサーバで基本的に対応は似通ったものになりますし、知識も共通のものを使えます。
これがアプリレベルまでメンテの範囲を広げると、途端にアプリについて仕様レベルから知識が必要になり、メンテできるサーバが激減します。
したがって、保守についてはOSレベルまでを広く見る担当とアプリ以上を見る担当を分離しておくとよいと思います。
どんなトラブルがあるの？
特殊な事例は山ほどありますが、機密保持に抵触する場合があるので、よくある事例を紹介します。
サーバの実例
よくあるのはハードディスク故障です。
これは本当によくあります。
それも保守期限が終了するとすぐに壊れます。
うちの部署はｘｘｘタイマーなどとよんでいます。
したがって冗長化は必須になります。
その他ですと、ログインまた特定ファイルにアクセスできなくなくなった、という障害も結構あります。
原因は、色々あります。
一つは物理的な経路異常。
これはサーバの障害申告としてスイッチ側に問題が出たケースが多いです。
まれにサーバの物理ポートが壊れたりしていますが、レアケースです。
あとは、管理権限でアカウントの権限の変更を間違えたなどがあります。
chmodなどの権限の意味を理解していない新人さんが失敗したりします。
スイッチの実例
べたなところですと、ポートの抜き差しを誤った、が挙げられます。
配線する際はそれぞれ刺さっているケーブルに用途や対抗装置を示すタグをつけるのですが、環境構成を頻繁に変更せざるを得ない状況だと抜き差し誤りのミスが生じます。
そもそも変更が生じているのだから初めの設計が悪い、といえばそれまでなのですが、立ち上げ初期だと割とポート変更せざるを得ない状況も生じるので、決して設計だけに責任転嫁できません。
実験環境あるあるかと思います。
あとはコンフィグの設定を間違える、が多いです。
特にvlanの番号の振り方を間違えるで通診断することが多い印象です。
どのvlanがどのスイッチにわたっていてどのポートから出られるかをきちんと把握していないと中継中のスイッチで遮断したりします。
メジャーどころはこんなところでしょうか
どうやってトラブルを解決するか
検証環境でトラブルをゼロにすることは無理です。
断言できます。
トラブル時にいかに素早くリカバリできるかがその人スキルの高さを表します。
トラブルには遭遇したくありませんが、管理経験を積むことがトラブル対処のスキルアップの唯一の道です。
知識としてわかっていても、実際に体が動かせるわけではないので、習うより慣れろの精神で戦うほかありません。
トラブルが生じた際は、スキルアップの機会だと思ってリカバリに動きましょう。
ひとつだけポイントがあるとすれば、異常が起きた際にまず疑うのはその時間にやっていた作業です。
何かが変わったことで、異常が出ていることは非常に多いです。
異常が起きた際にどこかの誰かが何かをやっていなかったかをまず調べてみてください。
