トライアルですがリモートワークが BeeX で始まりました
最近楽しいことがたくさんあって気分は最高です、那須です。
久々に技術とは関係ないことを書いてみようと思います。
私が所属している BeeX では、今日からリモートワークトライアルが始まりました。 私はすでにほぼ毎日リモートワークですが、他のメンバーは一部の人だけが自由にやっている、という状態でした。 今回はその様子をお伝えします。
リモートワークを始めるにあたって会社が場所を提供
うちの場合は、NewWork という東急さんが展開しているシェアオフィスを今日から自由に使えるようになっています。
www.newwork109.com
関東はあちこちにありますが、私は兵庫県に住んでいるのでこの勉強カフェに行ってみる予定です(今日はたまたま東京にいます)
www.newwork109.com
ちなみに、私は普段は↓このシェアオフィスを借りて最高の環境で仕事させていただいてます!
大人のワーカーが選ぶ会員制ワークスペースー Joe's Workspace Busico.
リモートワーク=家で仕事 ってイメージの方もいると思いますが、家にいると集中できなかったり、私の場合だと子どもたちと遊びたくなるので、無理やり外に出るようにしてます。 そして早めに家に帰ってきてから、ごはん、お風呂、続きのタスクを集中してやる、って流れにしています。
初日の様子
初日から早速使ってみたメンバーが Slack で状況を書いてました。みんな外の世界に興味津々です。
なんで全社でリモートワークが始まったのか?
分かりませんw
たまたま私がリモートワークで採用されてそれをきっかけにやってみるかーって思ったのか、リモートワークという言葉が巷によく出てくるようになったからなのか、事情は知らないのですがまあとりあえずいいことなのでうまく根付くといいなーと思っています。Facebook や Twitter で誰かが書いてくれるのを期待しておきますw
リモートワークって実際どうなの?
私はリモートワークを始めるといろんないい面が見えてきました。
- 家族と一緒に暮らせる(これが一番!)
- 家でも仕事できるので通勤って概念が薄くなる
- 仕事のプロセスが見えないので結果を強く意識するようになる
とまあ、ほかにもありますがほんとにいいことが多いです。3 番目に書いた結果の話ですが、これは人によっては嫌な面なるのかもしれません。
個人的に思うリモートワークが絶対必要な理由
労働人口が減るのが分かっている一方で、仕事したくてもできない人たちがいます。リモートワークって、この仕事したくてもできない人たちがいい条件で仕事できる手段になりえると思うんですよね。
例えば、
- 私のように関西やその他関東圏以外に住んでるけど家庭の事情で関東にいけない、でも素晴らしいスキルはある
- 育児等でしばらく仕事してなかったけど少しずつ時間ができてきたので昔のように仕事したい、でもやりたい仕事が関東圏にしかない
- 通勤そのものが苦痛でそれだけで体力消耗して仕事がはかどらない、自分のペースで仕事したいけど今の会社がそれを許してない
というふうに困ってる人たちが生き生きと仕事できるいい仕組みなので、私たちのようなエンジニア/コンサルタントにとっては必要な仕組みだと思います。 というか、これが当たり前になる社会に早くなってほしいと心から思っています。
まだトライアルだけど本稼働させたい
このトライアルでリモートワークしてよかった点やこれは改善した方がいい点を全員で洗い出して、リモートワークを正式に運用できるように本気出してやっていこうと思います。トライアルで終わってしまうのは嫌だw
一緒にリモートワークしてくれる人募集!
BeeX では AWS/Azure/GCP 等のクラウドエンジニアや、SAP テクニカルコンサルタントを募集してます!
採用ページは今リニューアルの真っ最中でもうすぐコンテンツが増えます。
BeeX に来て、仕事内容も働き方もバージョンアップしませんか?
とりあえず話を聞きたい、だけでも OK なのでいつでもご連絡くださいね!
プロフィールに Twitter のリンクをつけてますので、そこから DM なりしてもらうか、BeeX 採用ページから連絡いただくか、手段はなんでもいいので皆さんからの連絡まってますね!
www.beex-inc.com
AMI を作成する=バックアップをとる、ではないのかもしれない
バックアップ大事です。リストア確認も大事です。那須です。
結構時間がたってしまいましたが、Amazon Data Lifecycle Manager (Amazon DLM) が出てきましたね。 docs.aws.amazon.com
EBS スナップショット作成をスケジューリングしたり世代管理したりできるようになっています。 ここで皆さん思ったはずです。なんで AMI は対象外なのか? 同じバックアップなので簡単にできるんじゃないの? 案外すぐに AMI も対応するんじゃないの? つーか東京リージョンに来てくれ!
私も実際そう思いました。
でもふと立ち止まってちょっとドキュメントをいろいろ読み返してみたんです。そしたら気づいたんです。AWS さんはそもそも AMI をバックアップとは見ていないんじゃないかって。
定期的に Amazon EBS スナップショットを使用して EBS ボリュームをバックアップし、インスタンスから Amazon Machine Image (AMI) を作成して、それ以降にインスタンスを起動するためのテンプレートとして設定を保存します。
スナップショットは明確にバックアップ用途と書いてるけど、AMI はあくまでテンプレート扱いでどのページにもバックアップとしての記載がないんですよね(どこかにはあるのかな?見つけられてないだけで
というわけで、あえて運用中の EC2 インスタンスから AMI を作成せずにスナップショットだけでバックアップ&リストア対応できるかどうかやってみました!
とりあえずリストア
既にスナップショットでバックアップはとってあるものとして話を進めます。下の画像の test が運用中の EC2 インスタンス (Windows Server 2016) のイメージです。test のルートボリュームで障害が発生したので、test1 として新規に AWS さんから公開されている Windows Server の AMI からリストアするイメージで EC2 インスタンス (Windows Server 2012) を起動しました。本来は同じ OS のはずですが、わかりやすく見せるためにあえて OS バージョンを変えてます。
RDP で確認しました。確かに Windows Server 2012 です。id も i-0d630f0bbf6b5a05b です。
リカバリ開始
ではここからリカバリしていきます。まず、リストアした EC2 インスタンスを停止します。
ステータスが stopped になりましたね。
バックアップとして作成していたルートボリュームのスナップショットから EBS ボリュームを作成します。これで準備は OK です。
では、リカバリしていきましょう。リストアした test1 のインスタンスからルートボリュームをデタッチします。
先ほど作成した EBS ボリュームを test1 のインスタンスにアタッチします。
デバイスは、もともとのデバイス名である /dev/sda1 を指定します。
test1 のインスタンスのルートデバイスとして今アタッチした EBS ボリュームの id が見えてます。
そして test1 のインスタンスを起動します。
はい、起動しましたね。
RDP で確認してみましょう。インスタンス ID は間違いなく test1 のもの、でも OS バージョンが Windows Server 2016 になってますね。自分たちで AMI を作成しなくても Windows Server の EC2 インスタンスを復旧できました。ひとまず EBS スナップショットだけでバックアップ&リストア運用はできそうです。
あとはスクリプト化が必要かな
この流れを手作業でやってもいいんですが、オペミスや作業時間の長期化を避けるためにも aws cli 等で簡単に自動化しておくのが現実的だと思います。管理コンソールは画面が変わることがあるので、そのたびに手順書の画像を変えるのも大変でしょうし。 Systems Manager だけでなんとかできそうな気もしますね。
この手順が使えることを検証で確認できれば、Amazon DLM が東京リージョンにやってきた際にすぐにバックアップ運用に取り入れることができますね。
これからは AWS サービスの用途とか背景を想像してみる
AMI ≠ バックアップ という前提があってるかどうかはさておき、AMI はバックアップだ!という前提を疑うことでバックアップ&リストア運用の手段が増えたのが今回の収穫でした。 他にもこんなことがあるのかどうかわかりませんが、これからも考えを巡らせるクセはつけようと思います。