A Day In The Boy's Life -16ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

特に業務系のシステムの場合、そのサービスを利用するにあって何十ページもあるような分厚いマニュアルが作られたりもするんですけど、最初はユーザーのためにもマニュアルは必要と思ってたりもしてましたけど、最近はそもそもITサービスにマニュアル自体が向いてないんじゃないかと思ったりしてます。

 

 

マニュアルがあるせいで進化できないサービス

 

 

 

一つはマニュアルがITサービスの進化の過程で足かせになっているケースが多く見受けられることです。

 

マニュアルにはスクリーンショットと一緒に説明を入れたりするものが多いですが、そのせいで画面自体を変えることに抵抗されることがあったりします。

単にボタンの配置や色、表示されているメッセージを少し変えるにしても「マニュアルを差し替えないといけないからダメだ」(または時間をくれ)といわれることもあって、よりよい方向に変えるにもかなりの労力を費やす羽目になったりします。

 

また、そもそもITサービスの進化のスピードとマニュアルを整備したり教育したり、周知したりといった運用のスピードにかなりの差があったりして、一昔前ならこれは逆だったんでしょうけど今やシステムの進化や変化の方が早く、運用側がそれについてこれないといったこともあげられます。

 

もちろん、仕事が遅いというわけではないのですけど、教育したりそれを提供している客に連絡して現場で混乱しないようにするといったことは人間が介在する分、かなりスピード感がでなくなってきます。

システム開発のスピードは向上するものの、マニュアルなどは相変わらずオフィスソフトを使ってドキュメントを修正したり、メールやユーザーにお知らせする機能を使って情報を拡散するといった物理的な時間の制約が伴うものが多く、サービスの変化についてこれない状況になってきたりしています。

 

今やサービスの変化というのはよっぽど大きな変更は除いてユーザーに告知することなく(実際には告知はしているものの多くのユーザーはそれを知らなかったり)変わっている事が多々あったりします。

 

ソフトウェアを立ち上げるごとにバージョンのチェックが入って日々細々としたマイナーバージョンのものへとアップグレードが繰り返されてたりしますし、急にサービスメニューが増えたり変更となったりしていて不満を持ちつつも、使っている以上はそれに追随しなければならないわけです。

こういったことが当たり前の世界になりつつありますし、ユーザーもそれに慣れてきてたりもするので、そういったサービスの非情に短いサイクルでの変化の中でマニュアルの存在意義というのはますます薄れていっているのではないかと思います。

 

 

マニュアルがないと困るものはあるか

 

 

 

じゃあ、マニュアル自体は一切要らないのか、といわれたら個人的に困ることも多かったりして、例えば開発する上で必要なメソッドやAPIの仕様の説明、開発規則や設計書などはないと仕事にならなかったりするんですけど、こういったものでも最新リリースされたバージョンのAPIなどにきちんと付いていけているドキュメントとか少なかったりします。

 

まぁ、OSS系とかは有志によるものだったりしますので当然そういったドキュメントの整備とかはコミットされているわけではないですし、開発の第一人者やコミッタによって公開されている情報である程度概要がわかったり、そもそもOSS利用するなら自分でソース読めとか動作確認しろというのは当たり前だったりもするので文句はいえないところではあります。

 

結局のところ、ITサービスの進化についていくにはある程度自分で情報を追いかけていく努力が必要となるんでしょうけど、一般的なITサービスを使ってみても、初見で全く使い方がわからないといったものはほぼ無く(あったらたぶんそれ以上使わない)、そのマニュアルはUIの説明をするというよりは、仕様的な説明をするものに置き換わっており、これはマニュアルと呼ぶよりもどちらかというとFAQやQ&A的な使い方をしているものが多かったりします。

 

 

要は旧来のマニュアルといったものは役目を終えつつありますし、そういったものが無くてもわかるものが求められていたりしています。
数年前までガラケーだらけだったのに今やスマホだらけで、その過程で一定の不便さを感じることはありつつも、使い方が全くわからなかったという苦労をした人はあんまりいなかったんではないでしょうか。

 

現に、70歳を超える親にiPad渡してもすぐに使えていましたし、当時3歳の姪っ子も普通にYoutubeとか自分で見たりしているわけです。

 

まぁ、ユーザーによってはサービスや機器を使っていく中で結構細かいことを突っ込んでくる人もいたりしますし、特に機械系とかなら思わぬ使い方をして怪我をしたとかいった場合に訴えられても困りますからこういうことはしないでくださいって注意喚起をマニュアルに盛り込むようにもしたり、データが消えたとか保障する・しないとかの話も盛りこんだりということしているとかなり分厚いマニュアルができあがるわけですけど、こういったものはどちらかというとマニュアル自体が自己防衛の目的が強かったりします。

 

こういったものは利用規約などに吸収されてたりもするんですけど。

 

ということで、結局のところ分厚いマニュアルなんてユーザーは細かく読まないですし、マニュアルがなくて利用できるサービスというものがよいですし、同業他社のサービスに負けないためにも進化のスピードが求められてきますし、それを実現するためにも足枷になるようなものは作るに見合わないのではないかと思ったりします。

 

 

 

 

 

 

Linux環境上に何らかのデバイスを接続した場合、/devディレクトリ以下に/dev/sdXといったデバイス名が表示されますが、運用の中でデバイスが追加・削除されたりすると名前が変わったりしてシステム上良くないことが起きる場合があります。

特にストレージ領域をマウントしているといった場合、その接続デバイスの名前が変わることで正しくマウントできなくなったり、OS上で動かしているソフトウェアによってはデバイス名を指定しているようなものもあったりして、それが変わるというのは動作に支障が出るケースもあります。

 

今回は、以前に書いた「iSCSI経由でExt4環境のボリュームをマウントする 」のようにiSCSI経由でストレージに接続している環境下で、接続したストレージボリュームのデバイス名を固定化するというやり方を書いてます。

この中でもデバイス名を固定化するやり方は簡単に書いているのですが、ボリューム内にパーティションをきっていた場合、そのパーティション領域のデバイス名がうまく固定化できなかったことから、改めてまとめてます。

なお、ここで動作確認しているOSはCentOS6.6となってます。

udevのバージョンによって設定方法が結構違うみたいなのでOSのバージョンによっては設定内容が異なるかもしれないので注意してください。

 

 

udevを使ってパーティション領域のデバイス名を固定化する

 

というのが今回の趣旨ではあるんですけど、まず最初にOS上でiSCSI経由で接続されているデバイスの一覧をみてみます。

 

# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  8月 13 17:43 2015 ip-192.168.0.10:1234-iscsi-iqn.storage:0-12345-xxxxxxxxx-disk-lun-0 -> ../../sdc
lrwxrwxrwx 1 root root 10  8月 13 17:43 2015 ip-192.168.0.10:1234-iscsi-iqn.storage:0-12345-xxxxxxxxx-disk-lun-0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9  8月  7 10:35 2015 pci-0000:00:07.1-scsi-1:0:0:0 -> ../../sr0
lrwxrwxrwx 1 root root  9  8月  7 10:35 2015 pci-0000:00:10.0-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10  8月  7 10:35 2015 pci-0000:00:10.0-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10  8月  7 10:35 2015 pci-0000:00:10.0-scsi-0:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10  8月  7 10:35 2015 pci-0000:00:10.0-scsi-0:0:0:0-part3 -> ../../sda3

 

先頭の2つがiSCSIでつなげているデバイスで、下記のようにlun-0(sdc)がブロックデバイス、lun-0-part1(sdc1)がパーティションの構成となっています。

 

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1 1024M  0 rom
sda      8:0    0   16G  0 disk
├sda1   8:1    0  500M  0 part /boot
├sda2   8:2    0 11.6G  0 part /
└sda3   8:3    0  3.9G  0 part
sdc      8:32   0  105G  0 disk
└sdc1   8:33   0  105G  0 part

 

このsdcおよびsdc1というデバイス名を固定化する方法ですが、「iSCSI経由でExt4環境のボリュームをマウントする 」で書いた下記のようなudevのルールファイルを作成するとブロックデバイスに対してはデバイス名を固定化できるのですが、パーティション領域に関してはうまく動作してくれません。

 

KERNEL=="sd*", BUS=="scsi", PROGRAM="/lib/udev/scsi_id -g /dev/%k", RESULT=="36019cbd1a29432cc821b157e1600f0f1", NAME="bar%n", OWNER:="fuga", GROUP:="hoge", MODE:="0660"

 

このルールを適用すると下記のようにブロックデバイスとその中のパーティションとではデバイス名が変わってしまいます。

 

# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  8月 13 17:43 2015 ip-192.168.0.10:1234-iscsi-iqn.storage:0-12345-xxxxxxxxx-disk-lun-0 -> ../../bar
lrwxrwxrwx 1 root root 10  8月 13 17:43 2015 ip-192.168.0.10:1234-iscsi-iqn.storage:0-12345-xxxxxxxxx-disk-lun-0-part1 -> ../../sdc1

 

想定としてはパーティションの領域はbar1というデバイス名になってほしいところが元もとのsdc1のままになってます。

実際にデータがおかれているパーティション領域はOS上でマウントする際に/etc/fstabとかに書いたりするのでこのデバイス名も固定化しておきたいところです。

先ほどのルールで何が問題なのかというのは、このファイルでやっていることはPROGRAMで指定したコマンドを叩いてRESULTの結果が一致したら、NAMEに指定しているデバイス名を付けろというものですが、そもそもscsi_idコマンドはブロックデバイスに対してしかSCSI ID(デバイス固有の一意な識別子)を返してくれないみたいです。

 

ってことで、ルールを下記のように変更します。

ファイルは、/etc/udev/rules.d/80-scsi.rulesという名前で保存しています。

 

SUBSYSTEM=="block", ENV{ID_BUS}=="scsi", ENV{ID_SERIAL}=="36019cbd1a29432cc821b157e1600f0f1", NAME="bar%n", OWNER:="fuga", GROUP:="hoge", MODE:="0660"

 

ENV{ID_SERIAL}によって、デバイスのプロパティが指定のSCSI IDと一致した場合にデバイス名をbar%n(%nは順番に振られるデバイス番号)にしろというルールに変更しています。

 

このID_SERIALは下記のコマンドで確認できます。

 

# udevadm info --query=all --name=/dev/bar
P: /devices/platform/host17/session15/target17:0:0/17:0:0:0/block/sdc
N: bar
- snip -
E: UDEV_LOG=3
E: DEVPATH=/devices/platform/host17/session15/target17:0:0/17:0:0:0/block/sdc
- snip -
E: ID_REVISION=6.0
E: ID_TYPE=disk
E: ID_SERIAL_RAW=36019cbd1a29432cc821b157e1600f0f1
E: ID_SERIAL=36019cbd1a29432cc821b157e1600f0f1
- snip -

 

このID_SERIALはブロックデバイスに対してもパーティション領域に対しても同じ結果がセットされているため、ルールファイルの中でうまく マッチングさせることができます。

ルールファイルの表記に関する説明は下記に詳しく書かれています。

 

udevルールを処理するカーネルデバイスイベントへの影響 @ Novell

 

設定変更後は、udevを再起動します。

 

# start_udev
udev を起動中: [  OK  ]

 

これでもう一度、デバイス名を確認していると想定しているとおりbarやbar1のデバイス名になりました。

 

# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  8月 13 17:43 2015 ip-192.168.0.10:1234-iscsi-iqn.storage:0-12345-xxxxxxxxx-disk-lun-0 -> ../../bar
lrwxrwxrwx 1 root root 10  8月 13 17:43 2015 ip-192.168.0.10:1234-iscsi-iqn.storage:0-12345-xxxxxxxxx-disk-lun-0-part1 -> ../../bar1

 

ちなみに、ルールファイルが正しく読み込まれていたり適用されているか確認したい場合は、下記のコマンドでテストをすることができます。

引数に渡しているパスは、先ほどのudevadm infoコマンドの結果の中でDEVPATHに表示されているパスです。

 

# udevadm test /devices/platform/host17/session15/target17:0:0/17:0:0:0/block/sdc
run_command: calling: test
udevadm_test: version 147
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

- snip -
parse_file: reading '/etc/udev/rules.d/80-scsi.rules' as rules file
- snip -
udev_rules_apply_to_event: OWNER 502 /etc/udev/rules.d/80-scsi.rules:1
udev_rules_apply_to_event: GROUP 502 /etc/udev/rules.d/80-scsi.rules:1
udev_rules_apply_to_event: MODE 0660 /etc/udev/rules.d/80-scsi.rules:1
udev_rules_apply_to_event: NAME 'bar' /etc/udev/rules.d/80-scsi.rules:1
- snip -

 

かなり大量に情報が出てきますけど、最初のほうにルールファイルを読み込んでいるか、後半のほうにルールファイルに指定された名前などが適用されているかの情報で正しいかどうか読み取れます。

あと、CentOS5とかだとこのルールファイルは20-scsi.rulesのように若い番号で定義していたんですけど、適用する順番が変わったのかこのままだとうまく動作せず、80-scsi.rulesという後半の番号で定義するようにしました。

 

理由はよくわからないのですが、udevのデフォルトルールファイルが/lib/udev/rules.d/にあったりして、この辺のファイルが先に名前をつけてしまっているからなんじゃないかなと思ったりしてます。

 

 

 

 

 

情報を捨てるセンス 選ぶ技術/講談社
¥1,944
Amazon.co.jp


タイトルに惹かれて買った本なんですけど、今の時代の生きかたと言うものを捉えている本じゃないかなと思います。

どういったことを書いている本なのかというのは冒頭に以下のように書かれています。


本書の目的は、みなさんにより自信を持って、他人に依存せず、自分の頭で考え、賢明な意思決定ができる力を身につけてもらうことだ。他人の指示をやみくもに受け入れず、自分自身の直感や最初に抱いた考えさえもつねに疑うことのできる人になってもらうこと。つまり、大きく目を見開いて、自分の力で賢明な選択と決断のできる人になってもらうことなのだ。

今やネットで何でも探せる時代となっているわけですが、その利便性とは裏腹に情報量が多すぎて時には情報に踊らされたり傷つけられたりします。

そんな中で何を信じればいいのか、どうすれば釣られないのかというような情報ソースの追い方や検証の仕方なんかがTwitterやFacebookなどを中心にして実際に起きた事件や事象を絡めて書かれていたりしますので比較的とっつきやすい内容の本ではないでしょうか。


Twitterなんかを見てても嘘の情報というのはかなり多く流れてきますし、それを作り出した人に悪意があろうが無かろうが拡散する善意によって自体が悪化していくというようなケースもよく見ますし、何故それを本当かろくに調べもせずに鵜呑みにするんだろうという疑問を持つこともあったりするわけです。

また、ソーシャルの中で一定の権威を持つ人も含め、著名人とつながりやすくなったことでその行動や言葉に知らず知らずのうちに同調していくようなことがあったりします。


話題になっていることが必ずしも本当とは限らず、専門家の意見が常に正しいとも限らず、みんなの判断が必ずしも正しい結果になるとも限らないわけです。

当たり前のことなんですけど、圧倒的な情報量の前では考えることを止めてしまったり、知らず知らずのうちに自分の考えや行動が操られてしまうという危険性もあるわけで、こんな時代だからこそ情報に流されず考えて選択していく力というものが必要なんだと改めて思ったりします。


目次


Chapter1 選択と決断が人生を変える
Step1 めまぐるしく変化する世界とどう取り組むか?

Chapter2 目を見開いて世界を見る
Step2 正しい情報を見落としていないか?
Step3 言葉の力にあやつられていないか?

Chapter3 真実の管理人になる
Step4 専門家に服従していないか?
Step5 素人専門家を見逃していないか?

Chapter4 デジタル情報の海に溺れない
Step6 誰でも市民ジャーナリストになり得るのか?
Step7 なりすましとやらせを選別する

Chapter5 情報を選ぶ技術を磨く
Step8 数学から逃げていないか?
Step9 ”自分という受信機”をチェックしているか?

Chapter6 いまこそ変革を起こす
Step10 ”みんなの判断”に同調していないか?