それは目的じゃない
業務の中でサーバ管理者のようなことをしていると様々依頼を受けることがあるが、
以前から作業依頼のチケットの目的欄を見て思うことがある。
「それは目的じゃない」と。
A を B という状態に変えるという依頼の目的に、
「A を B にしたいから」と書いてあるのだ。知りたいことはそういうことじゃない。
ということでなぜ目的を適切に書いたほうがいいのか、もっともらしい説明文を AI に書いてもらった。
言いたいことはだいたい合ってる。
目的の重要性：依頼フォームにおける「目的」欄の正しい記入方法
目的とは何か？
まず、「目的」とは何かを明確にすることが重要です。目的とは、ある行動や作業を行う理由や意図を指します。単に「何をするか」ではなく、「なぜそれをするのか」を示すものです。目的を明確にすることで、依頼者と実行者の間で共通の理解が得られ、作業の意義や優先順位が明確になります。
目的の具体例
サーバ管理における例
NASのボリュームのマウント依頼
不適切な目的の記入例: 「NASのボリュームをマウントするため」
適切な目的の記入例: 「プロジェクトXのデータを共有するために、NASのボリュームをマウントしてチーム全員がアクセスできるようにする」
新しいユーザーアカウントの作成依頼
不適切な目的の記入例: 「新しいユーザーアカウントを作成するため」
適切な目的の記入例: 「新入社員が業務を開始できるように、必要なシステムへのアクセス権を持つユーザーアカウントを作成する」
日常生活における例
買い物リストの作成
不適切な目的の記入例: 「買い物をするため」
適切な目的の記入: 「今週の食事を準備するために必要な食材を揃える」
運動の計画
不適切な目的の記入例: 「運動をするため」
適切な目的の記入例: 「健康を維持し、体力を向上させるために週3回のジョギングを行う」
目的を明確にするメリット
作業の意義が明確になる
目的を明確にすることで、依頼された作業が何のために行われるのかが理解できます。これにより、作業の意義が明確になり、実行者のモチベーションが向上します。
優先順位の判断が容易になる
目的が明確であれば、複数の依頼がある場合でも、どの作業を優先すべきかの判断が容易になります。例えば、緊急性の高いプロジェクトに関連する依頼は優先されるべきです。
コミュニケーションの円滑化
依頼者と実行者の間で目的が共有されていると、コミュニケーション円滑になります。依頼内容に不明点があった場合でも、目的が明確であれば適切な質問をすることができます。
問題解決の効率化
目的が明確であれば、問題が発生した際に迅速に対応することができます。例えば、NASのボリュームがマウントできない場合でも、その目的が「プロジェクトXのデータ共有」であることが分かっていれば、代替手段を検討する際の指針となります。
目的の記入方法
具体的に記入する
目的は具体的に記入することが重要です。抽象的な表現ではなく、具体的な状況や理由を記載することで、実行者が依頼内容を正確に理解できます。
背景情報を提供する
目的を記入する際には、背景情報も併せて提供すると良いでしょう。例えば、プロジェクトの概要や依頼者の役割などを記載することで、実行者が依頼の全体像を握しやすくなります。
期待する結果を明示する
目的には、期待する結果も明示することが重要です。具体的な成果や達成したい目標を記載することで、実行者が作業のゴールを理解しやすくなります。
まとめ
依頼フォームの「目的」欄に何を入力すべきかについて考察しました。目的とは、作業の理由や意図を示すものであり、単に「何をするか」ではなく「なぜそれをするのか」を明確にすることが重要です。目的を明確にすることで、作業の意義が理解され、優先順位の判断が容易になり、コミュニケーションが円滑化し、問題解決の効率が向上します。具体的な記入方法としては、具体的に記入し、背景情報を提供し、期待する結果を明示することが挙げられます。
システム管理者と利用者の間でスムーズな作業が実現し、より効率的な業務運営が可能となるでしょう。
相変わらず鉄っぽい話題だが例を追加してみる。
いま渋谷にいて、「二子玉川行きの切符を買いたいんです」という人がいたとする。
これを文字通りに読めば、あっちの券売機で230円の切符を買って田園都市線に乗ってください、となる。
実際そういう人に目的を聞いたら「二子玉川に行きたいんだ」と言われ(て当たり前のことを聞くなと怒られ)ることも少なくないと思う。
ただし、目的や背景次第では提案は異なってくる。
東横線の定期券を持っているなら自由が丘を回ったほうが時間はかかるが安いかもしれない。*1
二子玉川の次の用事次第ではトライアングルパスを買ったほうがいいかもしれない。
バス停のほうが近ければバスでもいいかもしれない。さらに足が悪そうならタクシーを勧めてもいいかもしれない。
「〇〇が欲しいんです」だったらわざわざ二子玉川に行かなくても表参道とか、なんなら渋谷に売ってるかもしれない。
今どきなぜ切符なのかと疑問に思ってさらに話を聞けば、もしかしたら IC カードのチャージ方法を知らないだけなのかもしれない。
目的に対する解としてよりよいものを提案するのはもちろんだが、そもそもの解が異なっている場合もある。「運転免許を更新したい」だったら二子玉川と二俣川を間違えているかもしれない。
逆に目的が壮大すぎて訳が分からない場合もある。「よりよい人生を送りたいんです」などと飛躍していた場合はそこにたどり着くまでの順序を整理してあげないといけないかもしれない。
相手の置かれている状況と目的を理解し、こちらで提案できるもの・できないものを考えたうえでもう一歩踏み込んだ提案ができるかどうか*2、日頃仕事をするにおいてかなり重要な気がする。
一方、ここまで書いておいてなんだが別に"目的警察"をやってほしいわけでもない*3。 全部が全部に対してコンサルティングしろとも言わない。というかそんなリソースは無い。誰かのよりよい人生を送る手伝いを最後までする必要はない。
あくまでこれはコミュニケーションの一貫だ。双方が理解できて進められればそれでいい。 すべての依頼者に適切な目的を入れてもらうことは重要だが、それは目的じゃない。*4
産後パパ育休を使わなかった
2022年10月1日から産後パパ育休なる制度が始まった。
勤め先によっても運用に多少の差がありそうなので制度についての細かい話はしない。
この10月初旬に娘が生まれ1ヶ月の休暇を取ったのだが、
この産後パパ育休を使わずに有給休暇を使うことにした。
なぜ使わなかったか
収入が減る
会社からの給与ではなく雇用保険からの出生時育児休業給付金をもらうという扱いになる。
減ることはあっても増えることはないし、言うまでもなく減らないほうがいい。
有給休暇が余りまくっていた
ここが一番の理由になった。だいたい有給休暇を20日分使えば1ヶ月休める。
やはり手続きが面倒
産後パパ育休を使うことも検討はしていたので、会社の説明会は出ていた。
新しい制度ながらも会社としてはそれなりに準備していた印象だった。
使うにも通常の育休と同様の手続きになるので、書類をいくつか提出する必要がある。
人事労務の手続きを考えると一定の理解はできるが、
ここは率直に「面倒」という感想を残しておく。
上の話にも重なるが、有給休暇ならマネージャーに話を通しておけば数クリックで取れる。
いつ生まれるかわからなかった
出産予定日というのはあくまでも予定日である。
制度開始前の9月中に生まれたら面倒そうだという印象は拭えなかった。
ただこれはおそらく杞憂だし、もちろん今後使うだろう人には関係ない。
使えばよかったと思ったこと
有給休暇なので、期間の自由度がかなり高い。"いつ生まれるかわからなかった"ので、
この自由度はありがたいと思っていたのだが、盲点があった。
予定日よりも早く生まれることしか想定していなかったことだ。
同僚には「生まれてから1ヶ月休みます」と予定日の1,2週間前から伝えていたのだが、
予定日が近づくにつれて「いつから休み?」という質問が増えた。
休む休むと言っていた奴がだんだん手持ち無沙汰気味になりながら
まだ働いていればそうなるのも無理はない。
幸い予定日付近に生まれてくれたのだが、
もし2週間でも遅れていたらと考えると自分の想定の甘さを悔いていたと思う。
ちなみに産後パパ育休を使いつつ予定日から遅れて生まれた場合でも
生まれた日から起算し直すことになるので、
「いつまで休み?」というのは増えるかもしれないが、
少なくとも日程をハッキリさせることはできた。
使わなくても制度があってよかったと思ったこと
同僚には有給休暇を使って1ヶ月休むという話をしていたが、
仕事の性質上社内の複数部署の人たちとの関わりもあり、
自分がしばらくいないということは当然伝える必要があった。
その際「産後パパ育休です」と言えたのは楽だった。
これはもちろん方便だが、直接の上司や人事以外にとっては1ヶ月休むのに変わりはない。
そしてこの制度の存在自体が間違いなく休みやすい雰囲気作りに寄与しているんだろうと思う。
1ヶ月休んで
間違いなくやってよかった。
何がよかったか、うまく言語化された記事が最近出てたので最後に紹介して逃げるとして、
子育ての先輩やこれから子育てをするだろう友人といろいろな話ができるのを楽しみにしている。
IT-BCP を考える
IT-BCP とは
BCP とは、Business Continuity Plan の頭文字で、
簡単に言うと「何があっても事業継続できるようにするための計画」ということだ。
そして頭に IT が付いた IT-BCP は、
いかなるシステム障害にも耐えうるサービスを構築するための計画、
ということになる。Plan なので計画になるわけだが、
計画を超えて様々な場面で「BCP が〜」と言われるので既にバズワード、
しかも Google で検索する限りは日系企業が好んで使うガラパゴスなバズワードらしい。
何を想定するか
「何があってもサービスを落とさない」ために、
まずは何が起こりうるかを考えることになる。
AWS の東京リージョンが使えなくなるかもしれない。
k8s のクラスタが落ちたり、基幹データベースが機能しなくなるかもしれない。
大規模な災害起因だった場合、復旧にかかる人的リソースを確保できないかもしれない。
もしかしたら先日の log4j の脆弱性のようなものがきっかけかもしれない。
システムが複雑であればあるほど、考え出せばキリがない。
ここで大事なのは、落とさないために落ちることを考えること。
システム・アプリケーションに対する外的要因も想定しておくこと。
それはサービス、要はビジネスに対してどんな影響を出すのか考えること。
そして最も大事なのは、その機能・コンポーネントが機能停止した場合、
本当に復旧させる必要があるのかどうかを考えておくことである。
誰が想定するべきか
この手の何が落ちるか、ということを考えるには当然
開発者、運用を担う DevOps なり SRE が必須になる。
ただ、先ほど最も大事だとした点、「それを復旧すべきかどうか」
ということを判断できるのはシステムエンジニアではない。
ビジネスを担当している側、ひいては経営者ということになる。
エンジニアリングかつ経営も行なっている場合は別だが、
そうでない人にもこういう言い方をすると違和感があるかもしれない。
しかしこれは言い方を変えれば
「全てが落ちていた場合、どれから先に復旧させるか」
という話だ。
仮に、とある会社で新幹線の座席予約システムを開発し、
とある IaaS の単一リージョンで運用していて、
そのクラウドプロバイダのネットワーク障害で
トラフィックの数割は落としているような状態に陥ったとする。
そのプロバイダからの調査結果として完全復旧までの見通しは立っていないが、
隣の Availability Zone に VM を移動させれば問題ないというレポートが上がった。
しかしサービスとしてはただ移動させるだけではダメで、
ACL の再設定や DNS の切り替えなどが必要になることは分かっている。
今現在は新幹線の座席を検索して支払いをするまでに何度もエラー画面を出すような状態で、
SNS はユーザの不満であふれている。
今は辛うじて動いているが、このまま落ちれば新幹線の運行にも影響が出る可能性が出てきた。
果たしてこの状態で、旅先での宿も一緒に予約できる機能は
一体どの優先順位が付くだろうか。
冗長ならいいのか
先ほどの例はこれを書いている時点で新幹線に乗っていて思いついたもので
あくまで仮のものとして承知してほしいが、
「もともと AZ またぎで冗長構成を取れば良いじゃないか」
と思う人も少なくないと思う。
幸い DB 等とのレイテンシが許容される範囲で各コンポーネントを多重に
デプロイできる環境にあったとして、1つ大きな問題が出てくる。
それに必要な予算だ。
サービスを提供するために必要なリソースを100として2つの AZ に撒く場合、
50と50ではダメな場合がほとんどだ。片方が落ちた時に半分のリソースしか無いからである。
50が受けきれなくて落ちたら元も子もない。単純に100と100、というのではコストが倍になる。
ではオートスケールを実装して、となるとじゃあ平常時はそれぞれどのくらいがいいのか、
実際にスケールは間に合うのか、など様々検討しなければならない。
この AZ を分散させた時に必要な最大リソースは 1 + 1/n なので
実は分散させればさせるほど100に収束する。
が、分散させればさせるほどリリース(デプロイ)が複雑になる。
そして、大抵のアプリケーションはそう簡単に横に並べればいいものではない。
BCP は投資
今までの話を総合して、(IT-)BCP は投資であると伝えたい。
どうしても話の主人公がシステムになるし、何かしらのパラメータを変更するだけで
改善できるものも出てくるかもしれない。
ただし、そのシステム障害が起きた時にすぐ復旧させるためにも、
そもそもそのシステム障害を起きないようにするにも、何かしらのコストが必要だ。
経営者が「AWS 落ちても良いように BCP 考えといて」と投げるようではダメだ。
適切な被害想定と対策を出せるエンジニア組織、
最低限守るべきところを定義し、損失を正しく見積もれるビジネス、
費用対効果を見極め投資判断ができる経営、
この全てが揃って「何があってもサービスを提供し続ける」ことができるようになると考える。
CKAD 受けてみた
きっかけ
なぜか兼務がついている、勤め先の k8s バリバリ使っているらしい新規事業の子会社が
CKAD 向けのトレーニングと試験の費用を出してくれるというので
「主務違うけどいけるか〜」と思い申し込んでみたらいけたので12月に試験を予約した。
障害
ポケモンダイパリメイク
幼少〜学生時代にほとんどポケモンには触れなかった上、
Let's Go! イーブイもソードも持ってるだけで全然やってなかったはずが、
シャイニングパールの言語設定を英語で始めた途端ハマってしまい、
「勉強しないでポケモンやってた」という子供の頃みんなが言ってたアレを
今更ながら経験してしまった。
マジもんの障害
本業でここ数週間は「久々に来たね」と言われるようなトラブルが立て続けに起こり、
自分含め部署で生活リズム崩壊者多数、という状態になってしまった。
そして試験前日に CVE-2021-44228 が来てしまい、
内心「(無理じゃん…)」となっていた。
当日
試験は Webcam で自分の姿と画面を常に共有しながら行う。
周りに誰もいないこと、壁に余計なことが書いてないこと、
机の上と下に何も無いなどを証明しなければならないので、
休日に会社の会議室で受けようと決めていた。
とても気は重かったが頑張って行った。
試験時間になり、システム上でカメラをオンにして画面共有を開始しても
試験官から「見えん」と言われいろいろどうにかした結果、
Vivaldi をインストールしろという指示があって30分遅れでなんとか開始できた。
Vivaldi のダウンロードで20分弱かかったので、
もし受けるなら事前に入れておくのをオススメする。
この遅いダウンロード中に「遅いのでもうダメ」と言われなくてよかった。
(内心「遅いのでもうダメ、リスケして」を期待してなかったわけではない)
あと職場のネットワークのせいでもなくてよかった。
全部で17問あり、それぞれ重み付けっぽいことがされていて結果66%超えれば合格らしい。
最初の1問が解けずに心が折れて時間を使ってしまったが、諦めて次に行ってみたところ
意外といけそうだったり一瞬で解けたりする問題もあったので徐々に気を取り戻し、
最後の1問を読み始めたくらいで時間が来てしまった。
これから受けるなら
- Vivaldi 入れとく
- kubectl 慣れとく
- vim 慣れとく
- https://kubernetes.io/docs/ 慣れとく
- わからんやつはすぐ飛ばす
結果はまだ待っているが自信はあまりないので、
再試験が認められればもう1回頑張ろうと思う。
(追記)
なんと合格してました
2021年上半期・買ってよかったもの
下半期もこれをやる気はないですが、
今期は買いすぎたので懺悔の意も込めつつ。
1位 食器洗乾燥機
NP-TCM4
食器洗い乾燥機 NP-TCM4 商品概要 | 食器洗い乾燥機/食器洗い機 | Panasonic
良い点
料理も皿洗いも好きなんですけど、どちらも始めるまでが大変なところがあるので
片方解消されたのはありがたいですね。
あと手で洗うよりキレイです。
注意点
回すと部屋が暖まります。冬は助かるけど。
音がまぁまぁ気になります。
テフロン加工のフライパンは洗えないです。
2位 iPad Air 4 (+ Apple Pencil)
10.9インチiPad Air Wi-Fi + Cellularモデル 64GB - グリーン
10.9インチiPad Air Wi-Fi + Cellularモデル 64GB - グリーン - Apple（日本）
良い点
在宅勤務してて「図で書いて説明したい」が解決されました。
今はあんまり外に出ないので微妙ですが
単体で常にインターネットにつながっているのは楽です。
3位 デジタル一眼カメラ α7C
4位 iPad 用 Magic Keyboard
11インチiPad Pro（第3世代）・iPad Air（第4世代）用Magic Keyboard - 英語（US） - ホワイト
11インチiPad Pro（第3世代）・iPad Air（第4世代）用Magic Keyboard - 英語（US） - ホワイト - Apple（日本）
良い点
フリック入力よりキーボードのほうが速い人間なので楽です。
デザインも良い。
充電端子が増える。
MS Teams や Slack が PC なしでも使いやすい。
注意点
重い。
高い。
特に日本語入力で高速タイピングについてこないことがたまにある。
MS Teams や Slack を使っていると社畜感が増す。
5位 Amazon で買ったリングライト
ビデオ会議で自分を照らすために買いましたが、
それより手元が明るくなるのと深夜業務でも部屋の明かりを付けなくて済むので良いです。
番外編
PlayStation 5
買ってよかったというよりは買えてよかったですね。
ATEM Mini
ビデオ会議の映像入力に何でも入れられるのは楽しいです。
まぁまぁな値段しますし無くても困らないです。
ゼンハイザー MKE 200
風切り音がほとんど消えます。
使いこなすのはこれからですかね。
単焦点レンズ SEL20F18G
これも使いこなすのはこれからですかね。
動画編集アプリ LumaFusion
4K 動画の編集が iPad でできるので感動しました。
iPad の容量もっと多いのにすればよかったと後悔しています。
まとめ
書いてて思いましたが、YouTuber になりたいのか??という内容ですね。
これからも散財できるように引き続き頑張って働こうと思います。
最近あった Dev と Ops の対立
これは会社の同期アドベントカレンダーのためのものなので割とテキトーに書いてます。タイトルはたいそうなこと書いてますが半分ただの愚痴です。
---
SRE を名乗りながらも Ops 寄りの人間をしばらくやっているわけだが、最近あるサーバのある言語パッケージのバージョンが古いから更新してくれという依頼を受けて対応したのち、そのバイナリのパスが変わったから symlink を張ってくれという追加依頼をもらった。
.bashrc で PATH を定義しなさいと返すと、cron で使ってるからそれではダメだと言われ、そのスクリプトを書き換えなさいと伝えると変更とテストの工数が云々と言い出した。
マイナーバージョンとはいえ言語のバージョンが上がるのにテストをしないわけもないだろうし、スクリプト内のパスの定義を書き換えるのはテストが必要で symlink なら必要ないという理屈も理解できず、「数行変えるくらいでゴタゴタ言わなくて済むようにアプリケーションはどこでも動かせるようにしとけ」という旨の発言をしたのだが、symlink 入れればそのまま動くのにどこでも動くようにするのと矛盾しているなどという反論をされてしまった。
このやり取りをお互い喧嘩腰にしてしまったのは反省しているのだが、意図が伝わらず残念だった。お読みのみなさんならお分かりいただけると思うが、アプリケーションをどこでも動かせるようにというのは決してプラットフォームがアプリケーションに合わせる、という意味ではない。プラットフォームとは極力依存しないようにしてインターフェース部分は容易に変えられるようにするのが正しいだろう。自らの変更によるリリースで毎回怖気づくようではダメだ。
もちろん CI の文脈でもテストカバレッジが高ければより早く楽にこういうのも片付けられるだろうし、という話もできたかもしれないが、なかなか何をどう伝えるかは難しい。
SRE こそビジネスロジックを理解するべき
SRE という職種はまぁまぁ新しいものであるので、いきなり SRE を名乗ってビジネスキャリアがスタートするようなことはまだまだ少ないように思う。
自分が観測できる限りではあるが、
- 元 Dev
- 元 DevOps
- 元 Ops
の中でも Ops 色が強い人が多い気がする。
(ちなみにそれぞれの定義はせずに「かつてそう名乗っていた」程度にしておく。なんなら SRE の定義についても最近頭を悩まされている。)
そんな中で元 Dev であった自分が思うに、ビジネスロジックを理解している(理解しようとしている) SRE は稀な気がする。
また言葉の定義みたいな話になってしまうが、ここで言うビジネスロジックはもちろんソースコードに落とし込まれるような複雑なアレもあるが、ほとんど
そもそもそのサービスがどうやってマネタイズをしているのか
に集約されると思う。
ビジネスサイドは当然売上を上げ、コストを下げることに大きな目的を置いている。
拡大するサービスの規模に十分追いつくために、スケーラビリティを担保したアーキテクチャにするというのは当然なのだが、
だからといってコストをかけまくるわけにはいかず、限られたリソースで何ができるかが勝負になる。
この変化の激しい業界では突然どこかの会社と提携したり、突然 SNS でバズって流行り始めたり、突然どこかの大統領なり官房長官なりの発言に左右されたりすることも少なくない。
例えば「A 社と提携し、A 社の B というサービスと連携するようになる」場合、
ビジネスサイドの立場になれば何を狙いとして提携したのか、ユーザはサービスの何を利用するようになるのか、
A 社に対して自社は何を対価として提供することになるのか (=会社間の契約なのでユーザに直接影響しなくても SLA が高くなる傾向にある)
を判断し、必要な対策を取る準備をしなければならない。場合によってはすぐに対策を取る。
自らのサービスが置かれている状況が変わったときにシステムに対して何が起こり得るのか、どこに対策を行うべきなのか、極論プレスリリースの情報だけで推察できることは非常に重要である。
それは普段いかに開発側(可能であればビジネス側)とコミュニケーションを取っているか(情報をキャッチしているか)、システムの各コンポーネントの役割を理解できているか、
不確実性(外部経済、外部不経済と呼んだら良いのだろうか)と向き合っているかが問われる。
単にインフラ技術に詳しいだけではハッキリ言って足りない。
それらを踏まえると、「稼働率99.99%」が単なる数字では無くなってくる。
2020年は SLI がどういう意味を持つのかを理解し、定義し、可視化し、SLO / SLA を決めることができるかどうかが課題だと思っている。
