GIt入門 いまさらだけど基本的なことをまとめてみた！

Gitとは

Gitとはファイルのバージョン管理システムのこと

バージョン管理とは、ファイルの過去の状態も保存しておき、どのように変更されてきたか管理することを表している。

普段、WindowsやMacでエクセルファイルやテキストファイルを作って書いて保存して、を繰り返すと、同名ファイルは都度「上書き保存」されて、過去どんなことを書いて消してしまったのかが残らない。

一人だと過去の履歴が消えても、そんなに困ることは少ないが、 複数人でひとつのファイル（例えば経費管理のファイルや、Pythonのコードファイル）を編集するとなると、他の人が行った内容の変更に間違いがあったり、いまいちな点があったりして元に戻したい、となるときが結構ある。

そんな時に、過去の履歴があってすぐに戻せるとしたら、かなり助かるはず。

だからGitのようなバージョン管理システムが開発された。

基本用語

リポジトリ：過去のバージョンも履歴として残しておける、ファイルを保存するための貯蔵庫。個人リポジトリ（＝ローカルリポジトリ）と、共有リポジトリ（＝リモートリポジトリ）の２種類ある。

commit：個人リポジトリに変更を記録すること。要するにPC内にファイルを保存すること。

push：共有リポジトリに変更を記録すること。要するにインターネット上でチームなどと共有している場所にファイルを保存すること。

pull：共有リポジトリの情報を同期すること。要するにインターネット上の共有しているファイルの状態をPC内に持ってくること。

使い方

- インストール

GitはMacの場合、デフォルトでインストールされている。

$ git version
git version 2.16.1

Windowsの場合、自分でインストールする必要がある。

- 個人の情報を設定

GitHubでリモートリポジトリを使うために、gitを使い始める前にアカウントとメルアドを設定する必要がある。

$ git config --global user.name "自分のアカウント名"
$ git config --global user.email "登録したメールアドレス"

- PCに個人リポジトリ（＝ローカルリポジトリ）を作成

git init コマンドで現在いる場所に隠しディレクトリ ".git" が作成される。

$ pwd
/Users/hoge/.git/
$ git init
Initialized empty Git repository in /Users/hoge/.git/
$ ls -a .git/
.     HEAD        description info        refs
..      config      hooks       objects

.gitディレクトリの中には様々なファイルやディレクトリが生成される。

- ローカルリポジトリにファイルをcommitする

自分のPCのファイルをローカルリポジトリに置く前にステージングエリアと呼ばれる場所に置く必要がある。ステージングエリアに置くことで、このファイルをGitで管理するよ！と宣言することになるイメージ。 その後、commitしてローカルリポジトリにファイルを置くことができる。

$ touch test.txt
$ echo "This is test." >> test.txt
$ git add test.txt
$ git commit

git commit をするとvimが開くので、一番上にコミットメッセージを追記して、保存すればOK。 (vimが開いたら、Escボタンで編集できるようになる。メッセージを追記したらもう一度Escを押して、:wqと押してEnterすることで保存できる）

- gitで管理したくないファイル（例えばパスワードファイル）の設定

gitignoreというファイルを作り、その中に管理したくなりファイル名を書いて置くことで、commitされなくなる。

VirtualBoxでWindows10にUbuntu16.04の仮想環境を構築する

Windows10のPCにUbuntu16.04の仮想環境を構築します。

VirtualBoxを利用します。

まずは以下のページからVirtualBoxをダウンロード

→「Windows host」をクリックするとダウンロードが始まる

Downloads – Oracle VM VirtualBox

以下のページからUbuntu16.04をダウンロード

Ubuntu 16.04.5 LTS (Xenial Xerus)

ダウンロードしたVirtualBoxを開き、インストール

→ひたすら「NEXT」や「YES」を押すだけ

インストール後、VirtualBoxを起動すると、以下の画面が最初に表示される

 仮想マシン(VM)を構築するために、まずは「新規」をクリック

名前を入力して次へ

メモリを好きなサイズに設定し、次へ

「仮想ハードディスクを作成する」を選択して、「作成」

VDIのまま次へ

可変サイズのまま次へ

好きな名前を入力し、ディスクサイズを設定し、「作成」

仮想環境が追加された

電源ONする前に、 「設定」を押して、ストレージ→コントローラー：IDEの「空」を選択する

ディスクの絵をクリックし、「仮想光学ディスクファイル」を選択

先ほど、ダウンロードしたUbuntuのiイメージファイルを選択して開く

OKを押す

これでダウンロードしたディスクから起動されるようになった

「起動」を押して、新しいウィンドウが開くことを確認

 日本語を選択しようとウィンドウを押すと、以下の画面が出る

「仮想環境にマウスとキーボードの制御が持っていかれるので、ローカル(Windows)に戻したいときは、Right Conrtolを押す必要がある」という警告文

「キャプチャー」をクリックして、「日本語」をキーボードの矢印キーを使って選択し、Enterを押す

「Ubuntu Serverをインストール」でEnter

＜はい＞を選択 

「日本」のままEnter 

「Japanese」のままEnter 

「Japanese」のままEnter 

しばらくインストール処理が続く。。。

好きなホスト名を入力し、続ける

 好きなユーザの本名を入力し、続ける

好きなユーザ名を入力し、続ける

（このユーザ名が後ほどログインするときに入力するものになる）

パスワードを2回入力し、続ける 

短いパスワードの場合、上記のメッセージが出るが、気にしない人はそのまま進める

 暗号化してセキュリティを高めることができるが、気にしない人はそのまま進める

また、しばらく待つ。。。

 タイムゾーンが「Asia/Tokyo」になっていればそのまま＜はい＞を選択

なっていない場合は、＜いいえ＞を押して自分で設定する

「ガイド　－　ディスク全体を使い、LVMをセットアップする」でEnter 

 そのままEnter

 ＜はい＞を選択

 好きな容量を記入して＜続ける＞

 「パーティ初認具の終了とディスクへの変更の書き込み」でEnter

  ＜はい＞を選択

しばらく待つ。。。

プロキシが必要であれば入力して設定する

必要なければそのまま続ける 

またしばらく待つ。。。

意外と時間かかる、、、

 好きな項目を選んでEnter

 好きなソフトをスペースキーで選択してEnter

あとからでもインストールできるので、とりあえずそのままEnterでもOK

またしばらく待つ

＜はい＞を選択

ようやくインストール完了

ウィンドウが変わり、起動処理が始まる

しばらく待つとログイン画面になる

先ほど自分で設定したユーザ名とパスワードを入力してログインする。

あとは好きなように使っちゃってください。

昼飯後の眠気をどう解消するか？ 原因と対処法をまとめてみた

昼飯を食べた後に、自分のデスクに戻ってしばらくすると、ほぼ必ず襲ってくる眠気。

眠すぎて、気付いたら首がひん曲がっていたこともある。。。

そこで色々調べ、考え、まとめてみた。

まず気になるのは、昼食後に眠くなるのはなぜか、その原因

①脳に血液が回らないから

眠くなる原因としてよく聞くのは、

食べ物を消化するために、内臓に血液が回り、脳に血液が回らなくなるから、

ということ。これは確かに納得出来る。

そして、消化に時間がかかると、ずっと眠いということになる。

では、消化に時間がかかるのはどんな時か。

　・よく噛まずに食べる

　・消化の悪いものを食べる

　・水分の取りすぎで胃酸が薄まる

とかが思いつく。水分の取りすぎが良くないのは、何かの雑誌かテレビで言ってた気がする。

②血糖値が下がるから 

また、食後に血糖値が下がるから、眠くなる、というのもよく聞く。

なぜ食事で糖質を摂取してるのに、血糖値は下がるのか？

それは

「糖質を摂る（白米とか）と血糖値が上がる。すると体内でインシュリンと呼ばれる血糖値を下げる働きをするホルモンが分泌される。人間の眠気というものは、血糖値が下降したとき起こる傾向がある。」

ということらしい。（下記参照）

nemgym.com

つまり、糖質をとる→インシュリンが分泌される→血糖値が下降する→眠くなる、ということになる。

また、半概日性リズム（サーカセミディアン・リズム）という、１２時間周期で眠気がやってくる生活リズムも昼間に眠くなる原因とひとつらしい。（下記参照）

allabout.co.jp

つまり、たとえ昼食を食べなくても、人間の生活リズムから午後の眠気はやってくる、ということになる。

ここで昼食後に眠くなる原因をまとめると、

• 食べ物の消化により、脳に血液が回らなくなるから
• 糖質を摂取することにより、インシュリンが分泌され、血糖値が下がるから
• 人間の生活リズムが１２時間周期だから

では、どう対策すれば良いか。

・野菜を先に食べて、血糖値の上昇を緩やかにする

・15~20分くらい仮眠する(それ以上長いと深い眠りに入り、起きにくくなるため)

・仮眠前にはカフェインを摂る(甘いコーヒーは糖質を摂ることになるのでNG)

・ストレッチをして血流を良くする、すこしの間電気イスをして足の血液を脳に送る

・午後に人と会話する仕事、もしくは期限がせまっている仕事をする

・昼食時および食後に水分を取りすぎない

などが考えられる。

人の性格や置かれている環境はそれぞれ違うので、色々試してみて自分に合うもの、効果があったものを取り入れていくのが良いと思う。

とりあえず野菜を食べる🥦

ストレッチをする

Dockerのコンテナ環境をきれいに消す

Dockerの検証したり、動作確認したりしていると、Dockerイメージや停止したDockerコンテナがどんどん蓄積されていって、目当てのイメージやコンテナを見つけにくくなる。

そのため、一度Dockerのコンテナ環境をクリーンアップする方法をまとめてみた。

クリーンアップするDockerの３つの状態

dockerの状態としては３種類ある。
１：Dockerイメージ
　　→DockerHubから取得したり、自分のDockerfileをビルドして、ローカルに保存したイメージ
２：停止中のコンテナ
　　→Dockerイメージから作成されたけど、起動していない状態のコンテナ
３：稼働中のコンテナ

これらを全て消す。


稼働中のコンテナは削除できないので、一度停止(stop)する必要がある。
　→３：稼働中のコンテナ　があるとコンテナが消せない

コンテナが存在すると、そのコンテナで使っているイメージは削除できない制約がある。
　→２：停止中のコンテナ　があるとイメージが消せない

つまり、Dockerの依存関係として　３　→　２　→　１　の順に対応する必要がある。

クリーンアップのためのコマンド

①稼働中のコンテナの停止

　$ docker stop $(docker ps -q)

　　docker stop <コンテナのID>　でコンテナを停止できる。
　　docker ps でプロセスの状態を確認できる。

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
330ddbe7aee0        2b8caf31d8fe        "bash"              18 seconds ago      Up 17 seconds                           xenodochial_visvesvaraya

　　-q　はコンテナのIDだけを取得できる。

$ docker ps -q
330ddbe7aee0

　つまり、　docker ps -q で稼働中のコンテナのIDを取得し、それを　docker stop に渡している。

$ docker stop $(docker ps -q)
330ddbe7aee0

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES 

　↑稼働中のコンテナが無くなったことが分かる。

②停止中のコンテナの削除

　$ docker rm $(docker ps -aq)

　　docker rm <コンテナID>　ですべてのコンテナを削除できる。
　　docker ps -a　で停止中/稼働中関係なく全てのコンテナを表示する。

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                          PORTS               NAMES
330ddbe7aee0        2b8caf31d8fe        "bash"                   6 minutes ago       Exited (0) About a minute ago                       xenodochial_visvesvaraya
8aef7f9046fa        ubuntu-dev          "cc --version"           3 weeks ago         Exited (0) 3 weeks ago                              lucid_kowalevski
a542eca70416        ubuntu-dev          "ruby --version"         3 weeks ago         Exited (0) 3 weeks ago                              epic_brown
5225b7609af9        ubuntu-dev          "python --version"       3 weeks ago         Exited (0) 3 weeks ago                              relaxed_brahmagupta
c495fdee1b2b        ubuntu              "node --version"         4 weeks ago         Created                                             focused_aryabhata
0fd1dd889b0a        ubuntu-nodejs-1     "node --version"         4 weeks ago         Exited (0) 4 weeks ago                              practical_snyder
0f68c8d2e932        ubuntu              "/bin/bash"              4 weeks ago         Exited (0) 4 weeks ago                              heuristic_lichterman
c44cde856cf2        ubuntu              "cat /etc/lsb-release"   4 weeks ago         Exited (0) 4 weeks ago                              boring_rosalind

　　-q　はコンテナのIDだけを確認できる。

$ docker ps -aq
330ddbe7aee0
8aef7f9046fa
a542eca70416
5225b7609af9
c495fdee1b2b
0fd1dd889b0a
0f68c8d2e932
c44cde856cf2

　つまり、　docker ps -q で全コンテナのIDを取得し、それを　docker rm に渡している。

$ docker rm $(docker ps -aq)
330ddbe7aee0
8aef7f9046fa
a542eca70416
5225b7609af9
c495fdee1b2b
0fd1dd889b0a
0f68c8d2e932
c44cde856cf2

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

↑コンテナがひとつも無くなったことが分かる。

③イメージの削除

　$ docker rmi $(docker images -q)

　　docker rmi <イメージID>　ですべてのイメージを削除できる。
　　docker images　でローカルに保存されている全てのイメージを表示する。

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu-dev          latest              2b8caf31d8fe        3 weeks ago         625MB
ubuntu-nodejs-1     latest              e581036c1087        4 weeks ago         218MB
ubuntu              latest              735f80812f90        6 weeks ago         83.5MB

　　docker images -q　でイメージIDだけを確認できる。

$ docker images -q
2b8caf31d8fe
e581036c1087
735f80812f90

　　docker images -q で全イメージのIDを取得し、それを　docker rmi に渡している。

$ docker rmi $(docker images -q)
Untagged: ubuntu-dev:latest
Deleted: sha256:2b8caf31d8feb3b34708dce7cca268bd60ac9bf877b4bddcba030f27e7a46197
Deleted: sha256:55a35c78d72783d5c6bf1c6fdf4b3918b95cd39938ac06e0f6b5775d9c4775bc
Deleted: sha256:1fc5e8bd33c7b0c5c46db006e7000f130dd9fa5a4fcbe855fe69a4364f746477
Deleted: sha256:5cca3817cd7bdb896379de90c22a76ac89604aaf492d98079f0d78186aec259f
Untagged: ubuntu-nodejs-1:latest
Deleted: sha256:e581036c10872e09c924a830b291fe3d720bb9613dc43b0803d9c6f2eaf2fd80
Deleted: sha256:ec4c6cb855528774f3da2edebc93e3d5a3bd66e392b6c34c549ea75bd701b93f
Untagged: ubuntu:latest
Untagged: ubuntu@sha256:3f119dc0737f57f704ebecac8a6d8477b0f6ca1ca0332c7ee1395ed2c6a82be7
Deleted: sha256:735f80812f90aca43213934fd321a75ef20b2e30948dbbdd2c240e8abaab8a28
Deleted: sha256:86267d11f0c14fca869691b9b32bdd610b6ab8d9033d59ee64bdcc2cf0219bce
Deleted: sha256:d9a8b3f912eee0b322b86fa0f6888558a468c384611c71178987b20e3a0ebafc
Deleted: sha256:4e627d1476f22151f05e5214147d6cc6e03ad79a082f01aca6560aa75c7ade3a
Deleted: sha256:757b76a12baba45fcbe76abbdd99723be9d94c12a2ad40354dc49ff5fbe1f5c1
Deleted: sha256:f49017d4d5ce9c0f544c82ed5cbc0672fbcb593be77f954891b22b4d0d4c0a84

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

↑イメージが一つも無くなっていることが分かる。



以上で、コンテナ環境をクリーンアップすることができた。

余談：依存関係によるエラーメッセージ例

稼働中のコンテナは削除できないので、一度停止(stop)する必要がある。
　→３：稼働中のコンテナ　があるとコンテナが消せない


→稼働中のコンテナがある状態で、$ docker rm $(docker ps -aq)　でコンテナを削除しようとすると、以下のエラーメッセージが出る。

Error response from daemon: You cannot remove a running container 330ddbe7aee0ce0dc2da9692bfd1c890227a52c01c73d3a8d4b4fccc17b2961b. Stop the container before attempting removal or force remove

コンテナが存在すると、そのコンテナで使っているイメージは削除できない制約がある。
　→２：停止中のコンテナ　があるとイメージが消せない


→コンテナが存在している状態で、$ docker rmi $(dcoker images -q)　でイメージを削除用とすると、以下のエラーメッセージが出る。

Error response from daemon: conflict: unable to delete 2b8caf31d8fe (cannot be forced) - image is being used by running container 330ddbe7aee0
Error response from daemon: conflict: unable to delete e581036c1087 (must be forced) - image is being used by stopped container 0fd1dd889b0a

稼働中のDockerコンテナをバックアップとしてイメージ化して保存しておく

稼働中のDockerコンテナで開発をしていると、もしコンテナが落ちたら環境がすっ飛ぶよなあ、、、と不安になるので、バックアップを取れないか検証してみた。
（コンテナで直接環境を更新しているあたり、本来のDockerの使い方には合っていないんでしょうが、、、）

結論から

①稼働中のコンテナをcommitコマンドでイメージ化
②そのイメージをsaveコマンドでファイル化

でバックアップとして保存しておける。 コマンドは以下。

$ docker commit <コンテナのIDもしくはNAME>  <イメージ名>
$ docker save <イメージ名> -o <ファイル名>

では実際に

まずは、ホストマシンからUbuntu16.04のコンテナを作成して、bashで入る。

$ docker run -ti ubuntu:16.04 bash

コンテナの中に入ったあとは、デフォルトでは入っていないpython3を入れて環境を変更してみる

root@5207d7754fea:/# python3 -V
bash: python3: command not found
root@5207d7754fea:/#
root@5207d7754fea:/# apt update
〜出力は省略〜
root@5207d7754fea:/# apt install python3
〜出力は省略〜
root@5207d7754fea:/# python3 -V
Python 3.5.2
root@5207d7754fea:/#

バージョンが表示されたので問題なくpython3がインストールされた。

この状態のまま、他のターミナルを開き、Dockerのコンテナ状況を確認する。

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
5207d7754fea        ubuntu:16.04        "bash"              12 minutes ago      Up 12 minutes                           gifted_bhabha

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              16.04               52b10959e8aa        12 days ago         115MB

bashが稼働しており、またubuntuイメージだけがあることがわかる。

さてここからが本題。

①稼働中のコンテナをcommitコマンドでイメージ化

コンテナが稼働した状態のまま、イメージを取得して保存する。

$ sudo docker commit 5207d7754fea test_image
sha256:3c053ce8d919dd993c668bbcb7e27a740823e9ff8ec449b2fe4afe5cc6a096b6

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
test_image          latest              3c053ce8d919        9 seconds ago       193MB
ubuntu              16.04               52b10959e8aa        12 days ago         115MB

commitにより、イメージが作成されたことがわかる。
また最初に使ったUbuntuよりもサイズが増えているので、python3が入っていると推測できる。

commitのコマンドは、

$ docker commit <コンテナのIDもしくはNAME>  <イメージ名>

のようにして使う。

②そのイメージをsaveコマンドでファイル化

バックアップしたイメージはsaveコマンドでファイル化して、Docker環境の無いサーバやNASに保存しておくことができる。現在いるディレクトリに作成される。

$ docker save test_image -o test_file.tar

$ ls -ltr
total 193984
-rw------- 1 root root 198637568  9月  4 18:52 test_file.tar

あとはこのファイルをNASなどに保存しておき、いざという時に復活できるようにしておけばよい。
saveのコマンドは、

$ docker save <イメージ名> -o <ファイル名>

のようにして使う。

バッチ処理などで、定期的にこのcommitとsaveを実行するようにしておけば、突然サーバが落ちて、コンテナが消えても、最後のバックアップした状態までには戻せるようになる。

ファイルから復旧するには

ちなみにこのファイルからコンテナに復旧するには、loadコマンドとrunコマンドを使う。

一旦、イメージを削除する。

$docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
test_image          latest              3c053ce8d919        25 minutes ago      193MB
ubuntu              16.04               52b10959e8aa        12 days ago         115MB

$ sudo docker rmi test_image
Untagged: test_image:latest
Deleted: sha256:3c053ce8d919dd993c668bbcb7e27a740823e9ff8ec449b2fe4afe5cc6a096b6
Deleted: sha256:e36bc1738fb2f0e049abbc86a09f597ffb52e0be65bed049f36d49393326ee8d

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              16.04               52b10959e8aa        12 days ago         115MB

ファイルからイメージを作成する。

$ sudo docker load < test_file.tar
678bc467ee4a: Loading layer [==================================================>]  79.57MB/79.57MB
Loaded image: test_image:latest

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
test_image          latest              3c053ce8d919        27 minutes ago      193MB
ubuntu              16.04               52b10959e8aa        12 days ago         115MB

イメージが復活していることがわかる。 あとはこのイメージを使って、最初のように docker run するだけ。

短時間で正確にサーバの状態を把握するには

システムを維持管理している身としては、障害発生時などにいかに短時間で正確にサーバの状態や事象の中身を把握するか、が重要なポイントとなる。

そのためには、「基本を頭に入れておく」「根本をイメージする」という2点を身につけておきたい。

「基本を頭に入れておく」

細かいことはネットで調べながら確認すればよいが、基本的なことだけは頭に入れておくことで、素早い状況把握につながる。 例） - CPUやメモリの状況を表示するコマンドはtopやvmstat、sarがある - ユーザのログイン履歴やftp転送の履歴はどこそこのファイルに記録されている

「根本をイメージする」

上記の基本的なこと（コマンドやログ）において、根本的な挙動をイメージすることが正確な状況把握につながる。例） - topはどの情報を見た内容をサマリーとして出力しているか、を知っている - 稼働しているスクリプトのファイルの場所を知っており、いざというとき読み解くことができる - ・基本的なログの場所と読み方を理解している

具体的なフローとしては、こんなイメージ↓

---

たとえば障害が発生したとする。

① まずはtopやvmstatで最初は全体状況の把握に努める。

② 次は、事象によってプロセスやログを確認する。
　→ プロセスの確認としては、psコマンドから、現在何が稼働しており、どの程度のリソースを食っているかを確認する。
　→ ログの確認としては、/var/logにあるシステムログやアプリケーションのログを確認していく。ここで、稼働させているアプリケーションのログの場所と内容はあらかじめ理解しておくことが役に立つ。

③ それでも原因が特定できない場合は、パケットキャプチャやカーネルダンプなどの詳細なログが出力されるツールを稼働させることも検討する。ただし負荷が高いため、本番機ではなく、検証機や開発機など別環境で実施することも候補にいれる。

---

①〜②をいかに短時間で正確に実施するかによって、その後のシステム稼動の影響度が変わってくるため、重要なスキルだと考えている。

バッチの稼働時間を減らす方法

システムの維持管理をしていく上で、大切になるバッチの稼働時間。
この時間をなるべく減らす方法をメモ。

・並列処理可能なポイントを見つけ、処理時間の短縮化を図る
　→ただし並列処理にすると少なからず負荷がかかるので、用意できるシステムリソース（CPU、メモリ、ディスクサイズ等）との兼ね合いを見て設計する。パフォーマンステストが有効な判断材料となる。

・余計なログを取得しない
　→psを1秒ごとにとる、といった負荷の高いコマンドの高頻度での実行や、内容が重複しているログの取得
　→正常系のみ出力するログと、全て出力するログを両方取得するのは無駄だが、迅速な確認が必要なシステムの場合は、負荷とトレードオフを理解しながら、両方取得することもある

・負荷の高い処理は、Javaなどコンパイル言語の利用を検討する
　→スクリプト言語はその場で機械語に翻訳するため時間がかかる）

・再ラン性を持たせる
　→ファイルを中途半端な状態で出力しない、最初に初期化する、などが再ラン性があると言える
　→再ラン性自体は障害対応を迅速化させることに直結するが、すぐに再ランできるということで、結果的にトータルの稼働時間を減らすことにつながる