IT業界の新人さんに向けて(インフラ)

はじめに

こちらのコンテンツの導入部はこちらです。
まだ読まれていない方は、はじめに、をご一読頂けますと幸いです。
導入編

インフラ関連の内容

インフラの情勢(私見

世の中の流れとして、各種クラウドサービスが提供され、インフラの仕事は今後一部のトップ集団のみに任せられていくのではないかと考えられます。
ですが、ユーザーを各種クラウドサービスに導くためには、パソコン、OS、ネットワークなどのITインフラが必須です。

このように各種のシステムがクラウド化されることにより、インフラの業務自体はトップ集団に集約されていきますが、インフラの業務が全くなくなるわけではありません。
さらに、クラウド化されたからと言って、障害の切り分けなどにインフラの知識は必須ですし、ActiveDirectory(アクティブディレクトリー)、ジョブや監視などの分野も、クラウドサービスが台頭してきました。

• ActiveDirectoryとはWindows系サーバーOSが提供する認証基盤です。
  ActiveDirectoryを使用することにより、各種リソースへのアクセスが簡素化され、権限管理が可能になります。
  また、社員の使用しているWindows系OSの設定を強制的に変更することが可能になります。
  他の追随を許さないWindows系OS最強のシステム及びサービスです。
  30人程度の規模で権限、という概念が生まれた組織においては必須ともいえるシステムです。

各種サービスとITインフラ、切っても切れない関係です。

開発に強い方はインフラの知識習得を、インフラに強い方は開発の知識習得を目指しましょう。(自戒の念も込めて…)

インフラの整備

少しずつ改善を進めていく必要がありますが、インフラはとにかく検証/ノウハウの蓄積に時間がかかることと、お金がかかることが多いです。
端的に言うと、いいものは高いです。

特にシステム導入後にケアしにくいのが、冗長化とディザスタリカバリです。
規模として、ディザスタリカバリを考える必要が高くない場合もありますが、冗長化は各種システムを導入する際、常に頭の片隅に置いておく必要があります。
意外とバックアップも後からどうこうやりにくかったりします。
色々な経験を積んだメンバーで検討を繰り返して自分たちなりの正解を見つけていく必要があります。

• 冗長化とは、あえてシステムに冗長(無駄)を加えることです。
  例えば、ある機能を提供するシステムの最小構成がサーバー1台だとすると、そのサーバーを2台などの複数台で構成します。
  このように1台壊れても機能の提供が停止しないシステムを構成することを冗長構成とする、冗長化する、などといいます。
  やってみなければなかなかイメージがつきませんが、非常に難しいです。

• ディザスタリカバリとは、災害などの大規模の障害からの業務回復を考慮して、システム全体を構築することを指します。たぶん。
  複数のデータセンターに分散してサーバーを配置し、冗長構成をとらなければなりません。
  システムの使用者に拠点の変更を意識させずにディザスタリカバリを行うことは意外に難しいです。

ソフトウェアとハードウェアの概念

何をいまさら、と思われるかもしれませんが、ソフトウェアとハードウェアは別物です。
ソフトウェアの中には、ミドルウェア、アプリケーションなど様々な分野のソフトウェアがあります。
ここで大事なことは、OS(オペレーティングシステム)はソフトウェアである、という事に気づくことです。
インフラ経験者であれば、この概念はすっと入ってきますが、未経験者ではOSはあって当たり前のもので、なかなかこの概念の大事さが見えてきません。
この概念を理解しているか、していないかで仮想化の見え方が変わってきます。

仮想化の登場により、ハードウェア、ソフトウェアの境界すら、曖昧になってきています。
仮想化されソフトウェアでエミュレートされているCPUと、物理的なハードウェアで構成されたCPUの違いがイメージできるでしょうか。

ハードウェアをもう少し

IT業界では当たり前だと思われているため誰も教えてくれませんが、パソコンは大雑把に区別すると、HDD/メモリ/CPUで動いています。
それぞれが何をしているかざっくりとは把握していると思いますが、正確に何をしているかは、学者さんじゃないとわからないんじゃないでしょうか。
HDD/メモリ/CPUの役割を説明できる方は多いですが、それぞれのハードウェアがどのように連携して動いているのかを説明できる方は少ない印象を受けます。
ソフトウェアの概念も出てきますが、仮想メモリが腑に落ちているかどうかで理解度が違うのかな、と個人的には思います。
基本情報処理技術者試験など、馬鹿にできない知識を習得できる試験だと、私は考えます。

物理と仮想基礎

仮想化の登場により、様々なものが影響を受けました。
時系列はよくわかりませんが、おそらく最初の仮想化はアプリケーションの仮想化です。
(ストレージが最初かも知れません…？)
皆さんの良く使うExcelなどなどが仮想化され、各PCにインストールしなくても、アプリケーションサーバーにインストールされているExcelをあたかも自身のPCにインストールされているかのように使用できるようになりました。
(実行イメージをネットワーク経由でメモリ上に展開しているんでしょうけど、何をしているのか全く分かりません。とにかく天才って世の中にいるんですね！)

次に仮想化されたのはおそらくサーバーです。
仮想化といえばサーバー、というぐらいメジャーなものに成長しました。
その後、ネットワークの仮想化など、様々なものが仮想化されて行っています。

LinuxとWindowsの違いと得意分野

LinuxとWindowsの最も根本的な違いは何でしょうか。
それはマルチユーザーOSか、シングルユーザーOSか、だと思います。
が、この違いは最近は全く意識することがありません。
と言いたいところですが、やはりいまだにその違いを引き摺っていたりします。
Windowsはマルチユーザーで同時に使用することに弱点があります。
これはファイルロックなどの機構、ユーザーの切り替えに顕著に表れています。

例を挙げると、LinuxではユーザーAがファイルXをtailしながら、ユーザーBがファイルXへ追記する、ということが何も考えずに可能です。Windowsではファイルロックとユーザースイッチをクリアしないとこれができません。
これがログを出力するうえで結構な障害になることは、何かしらのスクリプトを複数同時に実行した際に理解することができると思います。
このように、複数のプログラムを同時に実行する、という部分でLinuxの方が優れています。
すべての処理を複数同時に他ユーザーを挟んで一瞬で終わらせてしまった時のLinuxさすが感はぜひ一度味わって頂きたいです。
本当にLinuxってすごい。

• tailって何？
  tailはLinux上で使用できるコマンドです。 tailを実行すると、ファイルを監視し、ファイルの末尾に追記された内容を画面にリアルタイムに表示してくれます。
  主に、何かのログをずーっと表示し続ける用途で使用するので、サーバーのログを見ながら、設定を変えてみる、などの際に威力を発揮します。

じゃあWindowsは？という話ですが、WindowsといえばGUIです。
何年も何年もクライアントOSのトップシェアで居続けているOSのGUIは、とんでもないクオリティになっているとお考え下さい。
Linux、Macは触れないけど、Windowsは触れる、という人が世の中の大多数を占めています。
そのWindowsのGUIのノウハウはWindows Serverへももちろん還元されており、複雑な設定を意識しなければ、ボタンをポチポチしていけばサーバーが出来上がり、動いてしまいます。
本当にWindowsってすごい。

色々とうだうだ書きましたが、この境界もあいまいになってきています。
お互いの良さをお互いに取り入れ、進化し続けています。
Linuxは権限管理の甘さをSELinuxという形で進化させ、様々な手法でGUIを構築しています。
バイナリをコンパイルしてインストールする、という文化もなくなりつつあり、どんなシステムもyumでパッケージからドーンッていう世界が来ています。
これに対してWindowsは、PowerShellによってシェルの手軽さを取り込みましたし、Ubuntu(Linuxのうちのひとつ)がネイティブに稼働する環境まで提供してしまいました。

• yumって何？
  yumはLinux上で使用できるコマンドです。
  yumを使用すると、必要なパッケージをほぼ何も考えずにインストールすることが出来ます。
  (Windowsでいうところのインストーラーの進化版とお考え下さい。
  パッケージの最新版を探し出し、ダウンロードしてインストールする、という作業をコマンド1発でやってくれます。)

• SELinuxって何？
  SELinuxはLinux上でセキュアなシステムを構築するためのリソース管理機能です。
  もろもろのソフトウェアを導入する際に障壁となることが多く、無効にすることが非常に多いです。
  が、そろそろ世の中的にはSELinuxに向き合い、うまく付き合っていこう、という考えが常識になりそうです。

• PowerShellって何？
  PowerShellはWindows標準で提供されるスクリプト言語です。
  Linuxのshellの良さを取り込み、そこに様々な独自文化を加えた不思議な言語に仕上がっています。
  Windows標準で提供される仕組みであるため取っつきやすく、簡単な処理であればすぐに試せるので、ぜひ遊んでみてください。
  開発の内容の際に、PowerShellを使って少し遊んでみようと思っています。
  Windowsの様々な機能をPowerShellから操作できるよう、どんどん拡張されており、将来性の高い言語です。

いつの時代でも、用途に応じて、使用者が向いているOSを選択する必要があります。
それぞれで何ができるのか、どんなことが苦手なのか把握しておくことは、OSを選択するうえで役に立ちます。

ネットワーク基礎

皆さん当たり前のように使用しているネットワーク。大まかな仕組みは理解できているでしょうか？
電気信号？電話？なんだかよくわからないけれども、難しいことは頭の良い学者さんたちに任せましょう。
ネットワークで大事なことは、ネットワークの分かれ目の理解とルーティングの理解です。

ネットワークって？

そもそも、ネットワークって何ですか？
IT業界でいうところのネットワークは、各システム同士をつなぐデータの通り道のことを指します。たぶん。
あるシステムを構築してもネットワークにつながなければ、誰もそのシステムを使いに来てくれません。
じゃあなんかのケーブルでつなげばいいの？っていうとまぁ、ざっくりいうとそうです。
正確に言うと、LANケーブルでつなげばネットワークが勝手につながるように誰かが準備してくれています。

ネットワークの分かれ目

大きなネットワークの分かれ目

すごく大きな括りでWAN(わん)とLAN(らん)に分かれます。
WANはいわゆるInternetのことです。全世界がつながっているネットワークをWANといいます。
LANは企業、組織、個人など小さな単位で管理されているネットワークを指します。
世の中のネットワークは膨大な数のLANとそれらをつなぐWANとで構成されています。

小さなネットワークの分かれ目

WANは世界の誰かが管理してくれているので分かれ目を意識することはほぼありません。
LANは自分たちで管理する必要があり、分かれ目を理解しておく必要があります。
LANって？

ネットワークアドレス	ネットワークの用途
192.168.1.0/24	1階の各種パソコン
192.168.2.0/24	2階の各種パソコン
192.168.200.0/24	サーバー室の各種機器

こんな感じです。
いきなりわけのわからない数字が出てきた。って感じですね。
1つを例にして、説明します。(ググるともっと良い説明がいっぱい出てきます。)
まず、ネットワークアドレスを以下の2つに分けて考えます。(そもそも24のところはネットワークアドレスじゃないんですけど…)
192.168.1.0
24

すごく乱暴に説明します。
192.168.1.0
の「192.168.」と「.0」は飾りみたいなもんです。(乱暴すぎます…反省してます。)
今回の例では、ネットワークを識別するための数字は「1」になります。
どこの数字に注目するかは「24」の部分が影響するのですが、複雑なことをしようとしなければ基本「24」です。
この考え方をすれば以下のように言い換えられます。

• 1階のネットワークは1
• 2階のネットワークは2
• サーバー室のネットワークは200

このネットワークを識別するための数字が違うと、別のネットワークになります。
別のネットワークに分ける意味が分からないと思いますが、ここまでざっくりと理解してください。

ネットワークを分割する理由

ネットワークを分割するのは様々な理由があります。

• ハードウェア/ソフトウェアの都合
• 接続する機器の台数の都合
• かけられるコストの都合
• 監査、セキュリティの都合
• 用途の都合

などなど…。

ネットワークを分割するって？

ネットワークを分割する、とはどういうことか。
まず大前提です。
分割されたネットワーク同士は、通信することができません。
ネットワーク上を流れるデータ(パケット)は、同一ネットワーク内でしかやり取りできません。
これを利用してアクセス制限として利用したり、ネットワーク内を流れるトラフィック(データ量)を抑えたりします。
異なるネットワークをつなぐ役目を担うのが、ルーターで、ルーターがパケットをルーティングすることで異なるネットワーク同士でも通信することができるようになります。

ルーティング

いよいよ出てきました。ルーティング。
異なるネットワーク間でパケットを中継することをルーティングというイメージはついたでしょうか。

ルーティングを理解するには、ルーターを理解しなければなりません。
さらに、デフォルトゲートウェイとゲートウェイも理解しなければなりません。
小規模の環境であれば、ルーターは(論理的に)1つしかなく、デフォルトゲートウェイは存在しますが、デフォルトではないゲートウェイはありません。

概念を理解する必要があります。
「各端末のネットワークの問い合わせ先 = デフォルトゲートウェイ」です。
皆さんも何かがわからなかったら、誰かに教えてもらうと思います。
各端末がネットワークについてわからなかった場合の問い合わせ先がデフォルトゲートウェイです。

例えば、ネットワークAに所属するパソコンXが、ネットワークBに所属するパソコンYと通信したいとします。

• パソコンXはネットワークBがどこにあるかわからないので、自身のデフォルトゲートウェイとして設定されているネットワークAのルーターにパケットを送ります。
• ネットワークAのルーターは、パソコンXから受け取ったパケットを、ネットワークBに送ります。

これがルーティングです。
ネットワークAのパケットがルーターを経由して、ネットワークBへ送られた瞬間こそ、ルーティングされた瞬間です。
なかなか理解しづらいのが、ゲートウェイという概念です。
ゲートウェイは各パソコンに設定されています。
当たり前ですが、ネットワークの設定経験が浅い方は、これを知らないことが多いです。
パソコンXのゲートウェイに、ネットワークAのルーターが指定されています。
以下はWindowsのPCでネットワーク情報を表示するipconfigというコマンドを実行した結果です。

ipconfigの結果

 イーサネット アダプター イーサネット 2:

    接続固有の DNS サフィックス . . . . .:
    IPv4 アドレス . . . . . . . . . . . .: 192.168.1.139
    サブネット マスク . . . . . . . . . .: 255.255.255.0
    デフォルト ゲートウェイ . . . . . . .: 192.168.1.254

このように、デフォルトゲートウェイは、各機器にそれぞれ設定されています。

名前解決とWebサーバー基礎

「名前解決」ってわかりますか？
普段当たり前のように使用しているのですが、IT業界でも知らない人がいます。
(最近はWeb系で当たり前に使うので知っている人がかなり増えてきている印象です。
業務の畑が違うだけなので、知らないからどうこう、という内容ではありません。)

「名前解決」とは、「名前」から「IPアドレス」を調べることです。
この機能をDNSと言い、この機能を提供するサーバーをDNSサーバーと言います。

具体的にはどういうことかというと、ネットワークを使って通信するためには、相手の情報を知らなければいけません。
相手の情報というのが「IPアドレス」になります。
先ほど出てきた謎の数字の羅列 …192.168.1.1… これがIPアドレスです。

世の中には、Webサーバーがあり、皆さん当たり前のように使用していると思います。
本来、Webサーバーへ通信する際にも、IPアドレスを指定する必要があります。
例を示すと、yahooの検索ページを表示するためには、Webブラウザで「118.151.231.231」を開く必要があります。
googleの検索ページを表示するためには、Webブラウザで「216.58.197.195」を開く必要があります。
…。覚えられませんよね。
皆さん、検索ページを経由しない場合、「www.yahoo.co.jp」や「www.google.co.jp」などでそれぞれのページを表示すると思います。

まさにこの「www.yahoo.co.jp」を「118.151.231.231」に変換し、「www.google.co.jp」を「216.58.197.195」に変換してくれているのが名前解決です。
ちなみに「名前」から「IPアドレス」を調べることを「正引き(せいびき)」、「IPアドレス」から「名前」を調べることを「逆引き(ぎゃくびき)」と言います。
これも、いつか役に立つかも知れません。

理解を深める

ちなみに以前同一ネットワークじゃなければ通信できないよ、という話があったかと思います。
異なるネットワークなのに通信できるのは、ルーターが必死にルーティングしてくれているからです。
「118.151.231.231」へアクセスするために、たくさんのルーター、たくさんのDNSサーバーが頑張ってくれて、yahooの検索ページが表示されています。
ルーティングの話と絡めて想像してみると、WAN、LAN、ルーターなど、ネットワークの全貌が垣間見えるかもしれません。

データベース基礎

これまでも十分ハードルが高かったのですが、ここでさらにもう3段ぐらいハードルが上がります…。
データベースのことをしっかりと説明できる人って世の中にいるんでしょうか…。

データベースとは

データがいっぱいため込んであるところ、です。
ため込んだデータを集計したり、膨大なデータから一部のデータを取り出したりするのが得意です。
最も良く使う概念として、行、列、表、があります。
そのほかにも多くの仕組み、概念がありますが、簡単な全体像と、行、列、表、を理解してみましょう。

理解しやすくするために

データベースはExcelに例えると理解しやすくなります。
またまた乱暴な例えになりますが、(Excelブックがインスタンスとすると、)Excelシートが表(テーブル)に例えられます。
Excelなら使い慣れてるよっていう方も多いと思います。
行(row)、列(column)、表(table)という概念はExcelと全く一緒といっても過言ではないので、Excelをイメージすれば表を理解しやすくなると思います。

データベースのプロを目指す

データベースが得意な方が世の中にはいらっしゃいますが、このような方々は「データベースからデータを高速に取り出す」事が得意です。
データベースからデータを高速に取り出すには、「データの積み上げ方、データの持ち方」も速度を意識して設計する必要があります。
「データを高速に取り出すことが得意な人 not equal データの積み上げ型、データの持ち方を設計できる人 ではない」のが残念なところです。
この両方ができる方を本当の意味でデータベースのプロ、と呼ぶんだと思います。

ただ、そういう方でも、データベースの冗長化や復旧あたりになってくると弱かったりするので、もはや一人でどうこうできる世界ではないのでしょう。

データベース技術の習得

データベースを自身で構築したことのある方はいらっしゃいますか？
また、そのデータベースにオブジェクトを作成し、データを蓄積し、活用してみたことはありますか？
これを両方やったことある方は意外と少ないです。
最近はそうでもないですが、データベースは、とにかく最初のハードルが高いです。

まずはSQL文のうち、単純なSELECTを理解しましょう。
基本情報処理技術者などIT資格の中で触りが出てきます。

覚える必要はありません。
google先生を使ってSQLが流せるようになりましょう。

データベースを操作する

データベースのデータをあれこれするには、SQL文を習得する必要があります。
SELECT文の本当に触りの部分だけ、説明します。

データベースからデータを持ってくるための命令です。
データベースに対して発行する命令のうち、最も影響が少なく、データベースを破壊することはありません。
(パフォーマンスに影響を与えることはあります…)
たくさんSELECTしてみて、早いSQLとは何なのか、遅いSQLとは何なのか、肌で感じましょう。

例えば、商品の一覧を表示するSELECT文は以下のようになります。
select * from products where disabled = 0
productsという表から、disabled列が0の行を抽出する、命令になります。

横文字を使うと、以下のように説明できます。

productsというテーブル(table)から、disabledカラム(column)が0のロウ(row)をselectする。
データベース感がようやく出てきましたね。

企業におけるデータベース

データを蓄積し、集計し、分析することに向いているのがデータベースですが、企業活動において、この3点は非常に重要です。
もしかすると、データベースにいかに効率的にデータを格納し、いかに高速に集計し、いかに生きた分析を行うか、によって企業の存続が左右されているのかもしれません。

データベースは企業としてクリティカルな要素だと考えていますので、データベースの活用を促し、発展させていく必要があります。
終わりのない世界ばかりですね、大丈夫、きっと楽しさを見つけられます。
楽しさを見出せるよう失敗を繰り返しながら成長し続けましょう。

バックアップ基礎

バックアップって何？っていう人はもう世の中にあんまりいないと思います。
簡単に言うと、データなどの資産を正/副準備して、正の資産が壊れた時に、副の資産から復元できる状態にすることを指します。たぶん。

バックアップする、という事

バックアップの設計をやったことがない人、経験が浅い人が陥りがちなミスとして、バックアップだけする、という事があります。
バックアップだけを目的としたバックアップは復元(リストア)ができないことが往々にしてあります。
リストア訓練を行え、というほど余力があることがない場合が多いのですが、リストアを考慮されたバックアップと、そうでないバックアップには決定的な違いがあります。

当たり前の話ですが、リストアできないバックアップはバックアップではなく、ただのコピーです。

世の中にはコピーを取ってバックアップと言い張る人がいます。
10個程度のファイルであれば、これでいいのかもしれません。
が、データベースのバックアップ、システムのバックアップなど、設計/構築できますか？

バックアップはそのイメージから簡単だと思われがちです。
ネットワーク/データベースなどに並ぶ主要な要素だと理解してください。
データベース同様、バックアップもなかなかお手軽に試せるものでもないので、技術者が育ちにくい技術のひとつです。

真面目にバックアップする

真面目にバックアップすると、どういうことを考えないといけないのでしょうか。
バックアップでだいたい問題になるのは以下の要素です。

• バックアップ時間
• どこの時点に復旧するか、復旧できるか
• リストアできるか

「リストアできるか」は前述の通り、生きた手順書があり、訓練を行っているか、が大事な要素になります。
そのほかの問題について、少し深堀してみます。

バックアップ時間

バックアップにも性能があるんです。
当たり前ですかね。
だいたいのシステムがそうなのですが、バックアップに割かれるコストは多くありません。
このため、数多くある各種サーバー/データに対して、バックアップサーバーは1台、という構成が非常に多いです。

これの何が問題なのかというと、一度に処理できるバックアップ処理数が頭打ちになってしまう事です。
バックアップ先(バックアップしたデータを保存する機器)の性能にもよりますが、並行してバックアップを取得する同時実行数はせいぜい3～5です。
同時実行数が3だとして、1サーバー1時間でバックアップが終わり、サーバー台数が9台の場合、単純計算で3時間かかります。
同時実行数をあげればあげるほど、バックアップデータの経路の性能の影響を大きく受けるようになりますので、本来、1時間で取得できるバックアップが、1.5時間、2時間…とどんどん遅くなります。
この積み重ねで、22:00に開始したバックアップが8:00になっても終わっていない、という状況が生まれます。

どこの時点に復旧するか、復旧できるか

「どこの時点に復旧できるか」、意味わかりますか？
バックアップを例えば毎日取得した場合、データ容量は日に日に増加し続け、いつか上限容量に到達し、バックアップを取得できなくなります。
つまり、どこかで取得してきたバックアップデータを削除する必要がありますが、削除できるバックアップデータとなる基準を設計する必要があります。
データ量が膨大になるにつれて、「壊れていることに気づくことができないデータ量」をいつの間にか超えてしまいます。

例えば一部のファイルが破損し、しばらく経ってしまった後に気づき、バックアップから復元しようとしたとき、「あれ？バックアップがない」となります。
このリスクをバックアップ設計者は負わなければならず、現場からは「バックアップ取ってるのに」と言われます。つらいですね。
無尽蔵に容量が増え続ける記憶媒体があれば、こんな悩みは無くなるんですけど、いくらするんでしょうね。

また、実際にデータが吹っ飛んでしまった場合、「どこの時点に復旧するか」の判断が必要になります。
「データが吹っ飛ぶ = 業務が停止している」という状況が多いため、この判断を瞬時に行い、復旧へ向けて行動することが求められます。
「どこの時点に復旧するか」の判断基準がない場合、この判断はバックアップ設計者にゆだねられる場合が多く、こちらもリスクを負わなければなりません。
滅多にないはずのデータ紛失、喪失ですが、起きる可能性という意味では、毎日、毎時、毎分、毎秒あります。
「障害時の最後の砦」であることの重さがのしかかってきます。

どうすればいいバックアップになるの？

リストアできるのはもちろんですが、前述の問題を解決するためには、バックアップを「設計」する必要があります。
具体的には、

• バックアップすべきデータを最小化する
• データを保持すべき期間を最小化する
• データの特性に応じて、バックアップ方法/バックアップタイミングを変更する

などと向き合い決めていく必要があります。
最小のデータ保持期間だけとっても、「取れるだけ取っといて」と言われることが多く、バックアップの設計は難航を極めます。
ありとあらゆるデータが「バックアップ」という言葉でひとくくりにされるため、考慮すべき内容が多く、データの特性やバックアップの経路の性能などをイメージしながら、リスクを負っていきます。
最後の砦として心配のないバックアップが構築できた時、それは間違いなく「良いバックアップ」です。

大丈夫、あなたの心配はバックアップの品質に反映されます。

ジョブ基礎

ジョブとは

ジョブとは、様々な処理を実行した際の管理単位、でしょうか…。
正直何なのかあんまり説明できません。

自動化してある処理をジョブ、と呼ぶこともありますし、自動化されていない処理をジョブ、と呼ぶこともあります。

ジョブを設計する

ジョブの設計、イメージできるでしょうか。
よくあるジョブは以下のような感じです。

• システム、サービス、サーバーなどを停止する
• メンテナンスタスクを実行する
• システム、サービス、サーバーなどを起動する

もろもろのメンテナンスをイメージするとわかりやすいでしょうか。

• 電車を止める
• 電車をメンテナンスする
• 電車を動かす

このように、関連性があり、前後関係のある処理を数珠つなぎにし、成功/失敗などの状況に応じて、システムのあるべき姿に導くことを「ジョブを設計する」というと思います。

システムのあるべき姿

例えば、以下のようなジョブがあり、1→2→3と順番に実行するとします。

1 システムAを停止する
2 システムAの構成ファイルをバックアップする
3 システムAを起動する

このようにジョブが組まれているとき、2のジョブが失敗して、処理が停止すると、3のジョブが実行されません。
2のジョブは業務継続という観点から、全く影響がなく、2のジョブが失敗したからと言って、システムAを停止したままにする必要はありません。

ジョブを設計するうえで重要になる概念は「システムのあるべき姿」を把握しておくことです。
このためにはクリティカルなジョブは何なのか、後続ジョブへどのようにつなげるべきなのか等々、全体の流れだけではなく、各ジョブの「あるべき姿」を把握しておく必要があります。
リカバリジョブなどの概念まで含めると設計すべき「あるべき姿」が非常に多く、全体を俯瞰しながら個別の内容も把握するという職人芸が求められます。

ジョブ担当の方からの問い合わせには、親身に答えてあげましょう。

監視基礎

監視を取り巻くイメージ

監視の重要性を理解していますか。
ふわーっと監視してるんだけど、あんまり気にしていないっていうのが多いのが世の中の常です。
この状況が問題視されているからか、大きな企業では監視部隊は独立されており、お役所のような仕事の仕方をしていることが多いです。
エラーが起きたら、エラーが起きたよ、と現場に問い合わせ、解決するまで許さないよ、という態度を取られることが多いです。

このお役所仕事のおかげで、ふわーっと監視がなくなっていることも事実ですが、監視部隊の方々は技術の向上が見込めない現場が多いです。
右から左に紙を回したり、閉じた世界で監視の設定変更だけを日々行っていては気が滅入ってしまいますし、他ジャンルの知識は積極的に取り入れなければ入ってきません。

世の中的には監視の重要性は謳われ続け、積極的に対応している会社/組織があることも事実ですが、まだまだその地位は低いままだと感じます。

悪いイメージの払拭

まず、監視に持っている悪いイメージを払拭してください。
例えばあなたが大手術を受けることになったとします。
その手術中、心拍を計られず、出血量も測定されないとしたらどう思いますか。

常に死と隣り合わせだと感じると思います。

監視はこれと同じです。
サービスを提供し続けているサーバーのCPU使用率/メモリ使用率などなどを見続け、異常があった場合にアラートをあげる、これが監視の根本です。

求められている監視

監視がどのようなものか、というイメージはついたかと思います。
では、求められている監視とはどのようなものでしょうか。理想の監視、すごい監視とは何なのか。
先ほど手術を例に挙げて説明しましたが、例えば以下のような対応はいかがでしょうか。

• 心拍の低下が検知されたので、心拍が上がる薬を投薬する。
• 出血量が基準値を超えたので、輸血を開始した。

手術を例にすると、「医師の許可なく勝手にやっていいのかよ」と思いますが、サーバーの場合、対処が確定していれば勝手にやってくれた方が楽ですし、勝手に対応すべきです。

• 発生した事象を事後対応するのではなく、起こりうる事象を検知し、事前対応する これが目指すべき監視です。

できる自信はありませんが…。それでも目指さないといけません。
だってそのほうが楽しいでしょう？

企業におけるインフラの動向

ITへ求められる成果は時々で変わると思いますが、維持はあまり求められていません。
維持はされていて当たり前で、変化/改善/発展/提案を求められていると感じます。

これを実現するためには、維持にかかっている工数を減らす必要があります。
ですが、維持は当たり前のもので、維持をしないわけにはいきません。
ではどうすればいいかと考えると、一番簡単に思いつくのは各種クラウドの利用です。

今後、各種システムをクラウドに移していく必要があると思います。
ただし、クラウドに移したからと言って維持がなくなるわけではありませんし、クラウドにはクラウドのデメリットがあります。
そのほかにいいアイデアがないか考え、何か見つけたら共有してください。
みんなで考えてください。

IaCや、コンテナ、オーケストレーション、世の中には楽しいものがいっぱいです！