ワルシャワ渡航記 Part1: 渡航準備

• Sep 16: I terminated my apartment lease contract.
• 更新月だったのでちょうど良かった。
• 今のマンションは2年しか住んでいない。
• Sep 16: My work permit has been issued.
• 申請自体は専門の担当の人がやってくれたので非常に助かった。
• 労働許可証が取れたので次はビザの申請が必要らしい。
• ビザの申請は自分で大使館に行く必要があるらしい。
• Sep 17: I passed checkpoint 1 on Duolingo. 
• 現地語まったく分からないのは困りそうなので、勉強中。
• Sep 18: I purchased a flight ticket.
• クレジットカードの認証が通らなくて困った。（このカード、昨年旅行予約しようとしたときもセキュリティに引っかかって使えなかったんだよな・・）
• 別のカードだと行けた。
• Sep 21: I made a visa appointment.
• ビザ申請のための予約をした。
• Sep 23: I applied for a vaccine passport.
• 紙のワクチンパスポートを申請するための書類を紙に印刷したり、必要書類のコピーを紙に印刷したりした。
• 申請は郵送で受付、返信用封筒が必要らしい。
• 世界標準のIATAトラベルパスの試験導入やってたけど、あれはどうなったのだろうか・・。
• Sep 24: I bought overseas travel insurance.
• ビザの申請で必要だったので保険契約をした。
• 必要とされる保険にいろいろと制約があって、一番安いやつでも20万円くらいした。
• Sep 26: I prepared documents to close down my business in Japan.
• 海外出国に伴い、個人事業主の事業を廃業するための手続きをした。
• 事業の開業〜廃業までの手続きを一通り経験できて良かった気がする。
• 申請書印刷するのが面倒くさい。すぐに申請フロー全体をシステム化するのは難しいと思うので、せめてEメールで書類送付できるようにして欲しい。
• Sep 28: I transferred my corporate DC assets to iDeCo.
• 前職の企業型確定拠出年金を個人型確定拠出年金に移換した。
• 税法上の非居住者は積立NGらしいので、掛金の拠出は行わず運用だけを行う「運用指図者」という者になった。
• Sep 30: I checked all the services I contracted in Japan to consider how to deal with them.
• 銀行引き落とし、クレジットカードの明細などをチェックした。
• 出国して使わなくなるサービスは解約する、使うかもしれないものは住所変更するという方針
• Sep 30: I got a certificate of residence for my visa application.
• コンビニで住民票取れるの感動した。
• Sep 30: I set up Skype for international call.
• Google Voice を使おうとしたが利用可能な国が限られているようだったので、Skypeを使うことにした。
• SMSの受信が出来ればSkype番号を取得して、それをどの国にいても繋がる携帯番号として使っていきたかったが残念。
• Oct 1: I changed cell phone plan and bought a new smartphone.
• SMS認証できないと詰んでしまうので、日本の番号でSMS受信するためのスマホを追加で持つことにした。
• 海外SIMを入れたスマホ、日本SIMを入れたスマホ、会社から配布されるスマホの3台持ちになる・・・
• 昨今の携帯料金大幅値下げのおかげで、トータルで考えると、これまでのプラン料金以下で3台持ちができそう
• Oct 2: I booked accommodation for the first few months.
• 渡航先のアパートの契約が決まるまでの一時的な住居を予約した
• airbnb を初めて使った
• Oct 4: I received all the necessary documents for my visa application.
• 依頼して2週間くらい経ち、ようやく日本の雇用主に依頼していた書類が届いた。時間かかりすぎや・・
• これでビザ申請の書類はすべて揃った！書類揃えるだけの簡単な仕事のはずだが、発行元が複数あったり、リードタイムが読めなかったり、求められるフォーマットに対応してもらう必要があったり、地味に疲れの溜まる仕事だったが、無事終わって良かった。
• Oct 5: I went to the consulate for my visa application.
• たぶん大使館に行くのは人生初。
• 面談を行う場合もありますとあったので緊張していたが、日本人の受付の人に書類を渡すだけで終了した。
• 2週間以内に結果が出ますと言われた。
• Oct 6: My visa has been issued.
• 仕事早すぎワロタ
• Oct 6: I'm going to close some bank accounts.
• 税法上の非居住者は維持できない銀行口座があるので、口座解約手続きを進めている。
• Oct 8-11: I met with my childhood friends.
• 遠方に住んでいる友達と会って回る旅に出た
• やっぱり子供の頃からの友達は無条件に良い。いろいろとエネルギーをもらって自分も頑張ろうと思った。
• Oct 15: I booked a medical check.
• 「現地で健康診断を受けてください。自分で現地の医療センターに電話して予約してね」という案内が会社から来た。
• 電話音声だけでコミュニケーションするのはレベル高すぎと思ったけど、思ったよりスムーズに会話できて良かった。もっと場数を踏んで英語強くなりたい。
• 途中で会社からもらった紹介状（現地語で記載）に書いていることを読んでくれと言われて、意味はわからなかったが読んでみたらちゃんと通じた。一瞬、Duolingo効果か？と思ったが、特別に訓練された海外担当デスクのオペレータの方の理解力の高さおかげだろう。
• Oct 21: I applied for a bulky waste collection.
• 不用品の回収をリサイクルショップ に申し込んだ。
• 購入してから1,2年程度の家電が多いので、そこそこの値段で売れるのではと期待。
• Oct 22-24: I met with my university friends.
• 大学時代にお世話になった会社の人たちと会ってきた。
• ソフトウェアエンジニアのキャリアの原点を思い出した。あの頃は朝までオフィスにいても楽しかったなぁ。
• Oct 26: I started packing my stuff for moving.
• 本とか小物などの荷造りを始めた。
• 2年前に引っ越したときに本やCD/DVDなどはだいたい処分したので、あまり物はない気がする。
• Oct 27: I donated foreign currency to UNICEF.
• 海外旅行＆海外出張で余った外貨をインテリアにして飾っていたが、ユニセフに募金してきた。
• コイン＆紙幣の量が多すぎて募金箱に入りきらず、JTBのお姉さんを困らせてしまった。
• 今度からは空港の募金箱にこまめに募金するようにしよう。
• Oct 27: I did the required procedures to stop lifeline services: gas, water and electricity.
• そろそろ退去日が近づいてきたという実感をえた。
• Oct 28: I went to the city hall to do the required procedures for leaving Japan.
• 海外転出届を出した。引越し先の住所を渡航国名にして、普通の異動届に書くだけでよかった。
• マイナンバーカードは返納しないといけないとどこかで見た気がするが、帰国後も番号は同じものが使えるので帰国まで持っておいてくださいとのこと。
• 国民年金の支払い猶予手続きをした。
• 大規模な事務手続きを想像していたが、転出届と年金手続あわせて2枚用紙に記入するだけの簡単作業だった。区役所の方の親切な対応に感謝。
• Nov 3: Recycle shop came to my house but they said they can't buy anything.
• 買ってから1,2年くらいの家電は売れるだろうと思っていたが、売れなかった。
• 処分料を払って引き取ってもらった。処分料は自分で捨てる手間を考えると妥当なものであったが、もう少し早い段階で複数の業者に見積もり依頼をしておけば違う結果になったかもしれない。引越しまで残り数日という段階で査定をお願いしても、こちらには交渉権がないので言われるがままなんだよな・・
• Nov 4-5: I packed up my things.
• 荷造りが思ったより大変だった。
• スーツケース1つで行けると思っていたが、2つ必要だった。
• Nov 6: I left my apartment.
• マンションの退去が完了した。
• ホテルへ移動。ケチって電車で移動したが、タクシー使うべきだった。スーツケース2つ持ちは想像以上に大変だった。

class SRE implements DevOps

SREに関する講座「class SRE implements DevOps」を視聴した。

 

簡単なメモを残しておく。

What's the Difference Between DevOps and SRE?

• DevOpsはDeveloperとOperatorの障壁を取り除くための指針
• Developerは新しい機能を早くリリースしたい
• Operatorはシステムが安定して動くように新しい機能をリリースしたくない
• SREはDevOpsの実装の1つ

SLIs, SLOs, SLAs, oh my!

• プロダクトごとに求められる availability は異なる
• availability の定義もプロダクトによって異なる
• SLI(Service Level Indicators) 過去5分間の95-percentile latencyが300ms未
• SLO(Service Level Objectives) 年間を通してSLIが99.9%正常である
• SLA(Service Level Agreements) 年間を通してSLIが99.5%未満しか正常でなかったらカスタマーに返金する

Risk and Error Budgets

• Error Budget = どのくらいの unavailability を許容できるか
• Error Budget が無くなったら、新しい機能のリリースはやめて信頼性の向上にフォーカスする
• Error Budget でアクシデント/リスクを数値化することで、アクシデントは起こって当然だと認識できる

Toil and Toil Budgets

• Overhead: Email, ミーティング、通勤
• Toil: プロダクションサービスの運用に関わるタスクのうち、繰り返し手動で行われる自動化可能なもの
• 障害対応もToil
• 障害対応を自動化するツールを書くのはToilではない
• すべてのToilが悪いというわけではない（新人が手動でシステムをいじって理解を深めるなど）

Now SRE Everyone Else with CRE! 

• APIを公開しているサービスはコンシューマにSLOを共有するべき
• Customer Reliability Engineering = Google Cloudでアプリケーションを作っているユーザのSRE実現をサポート

Managing Risks as a Site Reliability Engineer

• Risk Analysis = 考えられる障害のダウンタイム、影響範囲、頻度などを使ってSLOを達成できるかどうか調べる
• Risk Analysis を行うことで SLO 達成のために排除すべきリスクが分かる
• Risk Analysis を行うことで、現実的な Error Budget が分かる

Actionable Alerting for Site Reliability Engineers

• アクション可能で無い雑音のアラートはOFFにする
• SLOを使って実際にユーザに問題が発生している場合にアラートを出すようにする
• fast burn alert: 短期間のError Budget の消費量が異常 -> アラート、緊急対応
• slow burn alert: 長期間のError Budget の消費量が異常 -> チケット、業務時間内での対応

Observability of Distributed Systems

• structured logging: ユーザ情報が入った reqeust logs, サーバの debug logs
• metrics: クエリの数、レイテンシーの分布、CPUロードなど
• traces: 実行フローのタイミングや依存関係
• 失敗している処理の共通点（リージョン、コードのバージョンなど）を見つけることで原因を特定しやすくなる

Incident Management

• インシデント対応のときは明確なロールと責任を定義する
• 計画と実行を一人で行うのは難しいので分業が必要
• Incident Commander(IC): 戦略的な意思決定とロールのアサインを行
• Operation Lead: システムの理解と変更に責任を持つ
• 必要に応じて、ICはコミュニケーション機能やロジスティック機能（食べ物を買ってきたり、部屋の環境を整えたりする）を他の人に移譲することができる

Postmortems and Retrospectives

• ICがドラフトを作るが、すべてのロールの人が必要な情報を追記していく
• Blameless culture を持つことが大事
• Distributed System は様々な要素が絡み合って動作するので、root cause だけではなくすべての要素について記述する

Availability と Reliability の違い

　いまいち違いが分かっていなかったのでメモ。結論からいうと、用いる指標が異なる。

Availability（可用性）は稼働率を指標として用いる。

稼働率 = (経過時間 - ダウンタイムの合計時間) / 経過時間

これに対して、Reliability（信頼性）は MTBF（平均故障間隔）、または MTTR（平均修復時間）を指標として用いる。

MTBF (Mean Time Between Failures) =  (経過時間 - ダウンタイムの合計時間) / インシデント数

MTTR (Mean Time To Repair) =  ダウンタイムの合計時間 / インシデント数

Availability の方はシステムが利用可能な時間の話で、Reliability の方はどれくらい壊れやすいか、壊れたときにどれくらい早く対応できるかという信頼性の話をしている。

例を使って考えてみる。

• システムAは100日間のうち、1度インシデントが発生して、1日ダウンした
• システムBは100日間のうち、2度インシデントが発生して、それぞれ半日ずつダウンした

このとき、Availabilityで見るとAもBも99%で同じになる。

しかし、Reliabilityで見ると異なる。MTBFはAが99日、Bが49.5日となって、Aの方が壊れにくいシステムであることが分かる。逆にMTTRはAが1日、Bが0.5日となっていて、Bの方がトラブルがあったときに早く回復できるシステムであることが分かる。

個人的な意見だが、インシデント回数はコントロールできない外部要因に依存するので、エンジニア的には MTTR の小さなシステム（壊れてもすぐに回復するシステム）を設計するのが良いのではと思う。また、新機能の開発を控えればMTBFは大きくなるので、MTBFの増加に力を入れてしまうと、積極的な新機能の開発が行われにくくなってしまってよくないのではという気がする。

稼働率とMTBF, MTTRには以下の関係が成り立つ。

稼働率 = MTBF / (MTBF + MTTR)