パソラーです

https://twitter.com/pasora

産後パパ育休を使わなかった

2022年10月1日から産後パパ育休なる制度が始まった。
勤め先によっても運用に多少の差がありそうなので制度についての細かい話はしない。

www.mhlw.go.jp

この10月初旬に娘が生まれ1ヶ月の休暇を取ったのだが、
この産後パパ育休を使わずに有給休暇を使うことにした。

なぜ使わなかったか

収入が減る

会社からの給与ではなく雇用保険からの出生時育児休業給付金をもらうという扱いになる。
減ることはあっても増えることはないし、言うまでもなく減らないほうがいい。

有給休暇が余りまくっていた

ここが一番の理由になった。だいたい有給休暇を20日分使えば1ヶ月休める。

やはり手続きが面倒

産後パパ育休を使うことも検討はしていたので、会社の説明会は出ていた。
新しい制度ながらも会社としてはそれなりに準備していた印象だった。

使うにも通常の育休と同様の手続きになるので、書類をいくつか提出する必要がある。
人事労務の手続きを考えると一定の理解はできるが、
ここは率直に「面倒」という感想を残しておく。

上の話にも重なるが、有給休暇ならマネージャーに話を通しておけば数クリックで取れる。

いつ生まれるかわからなかった

出産予定日というのはあくまでも予定日である。
制度開始前の9月中に生まれたら面倒そうだという印象は拭えなかった。
ただこれはおそらく杞憂だし、もちろん今後使うだろう人には関係ない。

使えばよかったと思ったこと

有給休暇なので、期間の自由度がかなり高い。"いつ生まれるかわからなかった"ので、
この自由度はありがたいと思っていたのだが、盲点があった。

予定日よりも早く生まれることしか想定していなかったことだ。
同僚には「生まれてから1ヶ月休みます」と予定日の1,2週間前から伝えていたのだが、
予定日が近づくにつれて「いつから休み?」という質問が増えた。
休む休むと言っていた奴がだんだん手持ち無沙汰気味になりながら
まだ働いていればそうなるのも無理はない。

幸い予定日付近に生まれてくれたのだが、
もし2週間でも遅れていたらと考えると自分の想定の甘さを悔いていたと思う。

ちなみに産後パパ育休を使いつつ予定日から遅れて生まれた場合でも
生まれた日から起算し直すことになるので、
「いつまで休み?」というのは増えるかもしれないが、
少なくとも日程をハッキリさせることはできた。

使わなくても制度があってよかったと思ったこと

同僚には有給休暇を使って1ヶ月休むという話をしていたが、
仕事の性質上社内の複数部署の人たちとの関わりもあり、
自分がしばらくいないということは当然伝える必要があった。
その際「産後パパ育休です」と言えたのは楽だった。
これはもちろん方便だが、直接の上司や人事以外にとっては1ヶ月休むのに変わりはない。

そしてこの制度の存在自体が間違いなく休みやすい雰囲気作りに寄与しているんだろうと思う。

1ヶ月休んで

間違いなくやってよかった。
何がよかったか、うまく言語化された記事が最近出てたので最後に紹介して逃げるとして、

www.nikkei.com

子育ての先輩やこれから子育てをするだろう友人といろいろな話ができるのを楽しみにしている。

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月に試験を予約した。

training.linuxfoundation.org

障害

ポケモンダイパリメイク

幼少〜学生時代にほとんどポケモンには触れなかった上、
Let's Go! イーブイソードも持ってるだけで全然やってなかったはずが、
シャイニングパールの言語設定を英語で始めた途端ハマってしまい、
「勉強しないでポケモンやってた」という子供の頃みんなが言ってたアレを
今更ながら経験してしまった。

マジもんの障害

本業でここ数週間は「久々に来たね」と言われるようなトラブルが立て続けに起こり、
自分含め部署で生活リズム崩壊者多数、という状態になってしまった。
そして試験前日に CVE-2021-44228 が来てしまい、
内心「(無理じゃん…)」となっていた。

当日

試験は Webcam で自分の姿と画面を常に共有しながら行う。
周りに誰もいないこと、壁に余計なことが書いてないこと、
机の上と下に何も無いなどを証明しなければならないので、
休日に会社の会議室で受けようと決めていた。
とても気は重かったが頑張って行った。

試験時間になり、システム上でカメラをオンにして画面共有を開始しても
試験官から「見えん」と言われいろいろどうにかした結果、
Vivaldi をインストールしろという指示があって30分遅れでなんとか開始できた。
Vivaldi のダウンロードで20分弱かかったので、
もし受けるなら事前に入れておくのをオススメする。
この遅いダウンロード中に「遅いのでもうダメ」と言われなくてよかった。
(内心「遅いのでもうダメ、リスケして」を期待してなかったわけではない)
あと職場のネットワークのせいでもなくてよかった。

全部で17問あり、それぞれ重み付けっぽいことがされていて結果66%超えれば合格らしい。
最初の1問が解けずに心が折れて時間を使ってしまったが、諦めて次に行ってみたところ
意外といけそうだったり一瞬で解けたりする問題もあったので徐々に気を取り戻し、
最後の1問を読み始めたくらいで時間が来てしまった。

これから受けるなら

結果はまだ待っているが自信はあまりないので、
再試験が認められればもう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

α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 を決めることができるかどうかが課題だと思っている。

インド出張に行ってきた

概要

インド南部、バンガロールの子会社に出張に行ってきた。

環境

空気

到着して早速遠くがかすんでいた 。 持っていったマスクを屋外ではほとんど着けていた。

ホテルにも十分ペットボトルの水があり、会社でも水は汲めたので、水道水が飲めないのは意外と困らなかった。
どこ行ってもペットボトルの水は Bisleri というメーカー。

会社の食堂の皿は洗った後で少し濡れているのだが、ほぼ全員が近くの紙ナフキンで拭いていた。
理由を聞いてみると「不安だから」とのことで、現地の人も一切信用していない。

トイレ

紙が流せない。油断していると普段の勢いで流しそうになるので危ない。
ちなみに流す水は水道水より汚い。一体何がどうなってそうなっているのかわからないし、どうして日本は飲める水をトイレにも流しているのかもわからなくなってくる。

道路

汚い。歩道にはところどころに穴があり、工事中の管が中途半端に巻いてある。
上からは切れた電線がぶら下がっていてとても危ない。

車道には中央線こそあれ車線はほとんどお目にかかれない。車線が書いてあったところで誰も守っていない。
隙間があれば入るという感じで、とにかくクラクションを鳴らしまくる。車間距離を詰めまくる。多分それなりに接触している。全員が全員で常に煽り運転しているようなもの。
ただ鳴らす方も鳴らされる方も全然意に介さず、逆上する様子も無い。日本が煽り運転ひとつであんなに騒いでいるのがバカバカしく思える。

気候

暑いかと思いきや、曰く10月11月あたりは1年で最も過ごしやすい季節らしく、昼間もそこまで暑くないし朝晩は涼しかった。

料理

かなりおいしい。と思う。ただいちいち辛い
仕切りがある給食のお盆みたいなやつに数種類のカレーと米だったりナンだったりヨーグルトだったり辛くないものだったりキュウリだったりを乗せるのが南インド風の定番らしい。社食もそのスタイルだった。
この辛くないものというのがまた厄介で、激甘なのだ。
私が辛いと言いながら食べていると、ヨーグルトや甘いやつを食べるように勧めてくる。
要は辛いもの→ヨーグルト→辛いもの→甘いものと順番に食べるのが標準だというのだ。
「なんで極端に辛いのか極端に甘いものなのか、中間はどうした」と聞くと、苦笑いされてしまった。いや、辛いんじゃ。

こんだけ散々に言っているが、辛いけどおいしいのだ。やはりスパイスが日本のカレーとは全然違うんだろう。
特にビリヤニはとてもおいしかった。あと覚えているのはドーサ(クレープっぽいやつ、だいたいつけるものが辛い)とパニール(チーズのようななにか、だいたい辛いものに入っている)。
これはおすすめできるのでぜひ。

ご存知の通り牛肉は食べない。
が、飲み会で現地のマネージャーが「実は自分の出身地では牛を食べる文化がある。だから君たちと一緒で何でも食える」と言いながら牛肉を頼んで出してくれた。
まさかインドで牛を食べられるとは。

言語

全員英語を話す。
聞いたところによると地域ごとに地場の言語が違うらしく、隣町に行くと文字も言葉も全然わからないということがザラらしい。
ちなみに文字はだいたい中東のあんな感じのやつ(失礼)で、種類がたくさんあると聞いたところで区別はつかないし何も読めない。

まとめ

月-金の滞在で特に業務の話もしないのでこんなところだが、
正しいかどうかはわからないが現地の人に対して思った印象は「考え方がある意味合理的だな」ということだ。

既述の通り、社会インフラは到底整っておらず、渋滞にはまった救急車より歩行者のほうが早いようなところで何が合理的なのかというのは思わなくもないが、
そんな社会だからこそ個々人がいいように行動している。
だからこそ車線を無視して空いているところはどんどん詰める。あの渋滞ではそんなもの守っていたら前には進めないし、皆がその状況をわかっているのでお互いを咎めることもしない。
仕事の上でも「ルールだから」ということは全く通用しない。頼んだ仕事が期日通りに終わらないから怠慢な国民性、ではない。その仕事がどうして必要なのか、正当性をもって伝わっていない可能性が高いので反省すべきなのだ。
それを「発展途上のアジアの国ってそうだよね」とか「数十年前の日本はああだったね」と表現するのは簡単かもしれない。
ただ、ルールが一切通用しない今の人たちが数十年後にルールで縛られて今の日本のようになってしまうのは惜しいように思う。

最も印象に残っているのは、あんな環境で暮らしていて誰も死んだ顔して歩いていないことだ。
豊かさとは一体何なのかと思わされると同時に、また来たいと思わせる人生初めての出張だった。

月末、移動時間を業務時間にカウントしていいということで入れたところ法定外労働時間が一定ラインを超えてしまった。なんとまぁ。