はじめに
業務アプリケーションの開発をやってきていたが、もっと色々できるようなれば将来食いっぱぐれることが無くなるかなと思い
この度、運用DBAにスキルチェンジした。
一ヶ月仕事をしていった中で今まで気にしていなかった部分で指摘されることが多く
開発側と運用側では見る目線が異なると強く感じた。
また異なる部分を知っていく中で開発でも活かせると思い、その違いを忘れないようにまとめた。
引き出しの多さ
開発ではロジックを新たに生み出す(考える)作業だったが
運用では公開されている情報に対してどれだけ引き出しがあるかが重要
と書いたが、運用開発など関係なく引き出しは多ければ多いほどいい。
ここでいう引き出しというのは自身の知識だけでなくネットや書籍、その分野に詳しい知人などから
欲しい情報を得る手段のこと。
マニュアル
製品マニュアルこそ正義
製品について調べたときにググって上位に出てきたブログなどの内容をそのまま鵜呑みにしてしまうのは厳禁。
記事の内容が古かったり、対象としているバージョンが異なったりと信憑性が低い。
コマンド１つ１つに対してもなぜこのオプションの設定が必要なのかを製品マニュアルを見て確認する。
例えばjavaで文字列の処理をしたいだとかライブラリのインストール方法など
そのマニュアル(またはドキュメント)を見るとより理解が深まる。
作業手順の作り方
実際に作業する人が手順書を上から下までみないと何をしているか分からないような記載では不親切。
・エクセルならば1セルのなかに1コマンドだけを記載する。
・コマンドの実行結果の判断を記載する。
・どの接続先で操作しているのかのサーバ名、ユーザ名を明記する。
・繰り返し部分は省略せず実際にコマンドを打つ回数分記載する。
フォルダ権限
リモート接続先にファイルを転送する際はフォルダ権限を確認する。
作業手順書を作成する際に権限部分で躓くことがないようにしておく。
ログの監視
作業する時にはtailコマンドを利用して常にログを監視している。
Apacheの落とし上げなどで問題が起きた時だけログを見ていたが
それだけではダメで動作しているけど何か問題が発生している可能性もある。
それを確認すべき。
表領域、ディスク容量の監視
「サーバ＝高スペック高容量」と思っていて何も考えずにサーバにファイル転送を行っていたが
サーバはこのぐらいのスペック・容量が必要だと考えられて構築されているので無制限に使えるほどの容量はない。
そのため、データ転送が伴う作業には必ず容量あふれが発生しないか確認・監視する。
LV(論地ボリューム)の分け方
Linuxでは論地ボリュームを作成して物理ディスク容量を抽象化している。
バックアップファイルやログファイルなどデータが増大していく場所については
LVを別に割り当てて、物理ディスク拡張時の管理を容易にする。
「LVってレベルのことですか？」と聞いたら全然違っていた。
またこういった略称でのやり取りが非常に多い。
X Window
リモート接続先のGUI画面をローカルPCに表示する。
生まれて初めて聞いた用語だがLinuxを扱う人には一般的らしい
まとめ
実際に書いてみるとそんなの当たり前でしょと言われそうな事が多かったが、
今までそんなに深く考えていなかった。。
特に重要だと思うのがマニュアルを見ること！
マニュアルすべてに目を通せっていう話ではなく必要なことをその都度、マニュアルで調べたほうが理解が深まる。
いま考えるとプラモデル作るときは必ず説明書みて順番通りに作っているのに、Apacheインストールするときには説明書(マニュアルやドキュメント)を見ないとか
やっていることがおかしいかった。
これから新しいことを学ぶ上で思うこと
DBAになるためにオラクルシルバーを取って基礎知識を蓄えた気になっていたが、
実際に作業をすると何やってんのかよくわからない。
「あー試験でたなそれ」と思えるぐらいの浅い理解しかできていなかった。
やっぱり困らないと調べることはしないし、困ったことを調べて解決していかないと深い理解ができないと強く感じた。
まずは基礎を１から１０覚えてから応用へ！！っよりはある程度やりたいことを決めて、その目的を進めていくうえで必要となった基礎を覚えていくほうがよい。