ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

CloudGarageのDevAssistProgramに通ったのでさっそくインスタンス作ってみる

はじめに

CloudGarageのDevAssistProgram通りましたー!

CloudGarageさんは定額制のパブリッククラウド。利用料金にビクビクすることがないのでいいですね。

そしてDevAssistProgramです。

cloudgarage.jp

LBが1つと、インスタンス3つもついてきます!なんと1年間無料。承認制です。

わたしはいのうえさんのkubernetesの記事でこのキャンペーンを知りました。

blog.a-know.me

こちらもぜひやってみたい。

注意

審査が通ったあとは、アカウントを作成し、再度アカウント名をメールで送信することでアカウント情報と紐付けされ、キャンペーン対象を無償購入できるようになります。そのため承認がおりても使えるまでは多少タイムラグが生じるのでなるべくはやく返信しましょう。

使ってみる

ではさっそくコントロールパネルからインスタンスを作ってみましょう。

無事審査が通ると以下の画面でキャンペーンプランを購入できます。

f:id:take_she12:20171012182227p:plain

インスタンス作成です。OSはCentOSUbuntuDebianfedoraSuSEといろんな種類が使えますね。Rancherがあるのがめずらしいと思いました。Docker環境がらくらく作れちゃいますね。

f:id:take_she12:20171012182234p:plain

逆にアプリケーションが乗った状態で配られるものもあります。GitlabやRedmineはだいぶインストールが楽になったとはいえ、ソッコー使えるのは結構嬉しいですね。Gitlabはgitlab.comが代替になるとして、個人用のRedmineは欲しいと思ったことあるな。(音楽制作のプロジェクト用に)

f:id:take_she12:20171012182240p:plain

インスタンスを作ると10秒そこらで稼働中になりました。ポートはhttpの80番とsshの22番だけあけておきました。

f:id:take_she12:20171012182249p:plain

実際にログインしてみます。

rootユーザで、インスタンス作成時のパスワードを入力すればログイン完了!

⋊> ~/g/private on master ⨯ ssh root@203.104.226.212                                                                   18:31:39
root@203.104.226.212's password: 
Last failed login: Thu Oct 12 18:26:25 JST 2017 from 171.233.59.3 on ssh:notty
There were 16954 failed login attempts since the last successful login.
Last login: Mon Jun 26 13:22:52 2017
[root@cloudgarage1 ~]# 

22番公開してるからかめちゃくちゃログインアタックかけられてますねw やっぱりport番号は変えないとダメかな。

[root@cloudgarage1 ~]# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 

OSはちゃんとCentOS7.3です。

おわりに

(このインスタンスはちゃんと破棄しました)

インストール直後のセキュリティまわりの設定はあとでするとして、個人でLBつきの3台使えるのは開発者にとって非常にうれしいことです。上記のkubernetesだったり、redmine個人用に作ったりもしてみたいですが、まずは直近仕事で使うMariaDBのGalera Clusterを試します。

というわけでCloudGarageの宣伝&導入記事でした。(別に頼まれてません!)

今のチームで自分が貢献できること、貢献していきたいこと

はじめに

ふと思いついたテーマ。

自分の実力、技術がオープンに評価されることがもっとも望ましいことではあるけど、それが必ずしもオープンで、ワールドワイドな評価でなくてもいいと思う。仕事をしていく上で、自分が今いるチームでどんな価値が発揮できるか、自分の得意なところなどこなのかを自覚しておくことは大切だと思い、書き記しておく。

チーム内で自分が相対的に優れていると思うこと

最新技術動向のキャッチアップとアウトプット

1人化け物みたいなひとがいるのですが、それは置いておいて、定期的にmenthas.comさんを見ていること、Twitterの技術アカウントのタイムラインを見ていること、後述しますが社外勉強会に参加していることから、少なくとも語彙という意味で最新技術情報は知っているほうです。

1人化け物*1みたいなひとがいるので、そのひとに食らいついていきたい。

CI/CDまわりのツール・フレームワークの技術知識

前のチームでそれら専任チームをリードしていたので当たり前といえば当たり前ですが、チーム内では教えることができる立場にいます。

そもそもgit(github flow)の使い方からあやしいひともいるので、gitというツールの使い方からサポートしています。

具体的には以下のような感じ

  • git
  • gitlab
  • gitlab-ci
  • jenkins
  • ansible
  • capistrano
  • serverspec

OSSの構築とチーム内導入

自由に使える仮想環境とIPアドレスを持っていることもあり、これまで様々なOSSを持ってきては試してみる、ということをやってきました。

  • phpipam
  • minio
  • mattermost
  • jenkins
  • knowledge
  • etherpad

自分で探して使ってみる、ということもありますが、「これ便利だから使いたいなー」という声を聞いて立ち上げた例もあります。Webアプリケーションの構築、セットアップ、導入をスピード感を持ってできる点は優れていると思います。

仕組み変えるための提案能力

何か仕組みを変えるための説明資料の作成と、説明して変更、受け入れてもらうプロセスを素早くやることができます。

これも前の仕事で開発プロセスのルール変更を外側からやった経験もあることと、様々なツールを導入して展開した経験も相まって、使ってみる、試してみる、誰もが使えるようにする、ということは得意です。

また、必要であれば図示して公開、ひとを集めて説明することで、これは何のために、どうやって使うのかを説明し、すぐに使える体制にすることができます。使ってみてのフォローまで行ってきました。

新しいテクノロジーの導入であったり、課題を仕組みから解決することを任されると、結構楽しくやれますね。

チームのパフォーマンス向上

マインドの問題ですが、誰よりも属人化を嫌っているので、チーム全体としての底上げは常に意識しています。勉強会のリードしたり、自分ができることをあえて別のひとにやってもらってフォローすることで、全員がいろんなことをできるように、じわじわ少しずつ広がっていくような仕掛けを出しています。

チーム内で自分が相対的に劣っていること

もちろん劣っていることはたくさんあります。詳細にはあげませんが、以下。

  • Pythonのコーディングスキル
  • OpenStackの内部ロジックの知識
  • データベースのパフォーマンスチューニング
  • オープンソースコミュニティへのコントリビューション

これらはこれから伸ばしていかないといけない部分です。

得意なことと活かしてチームにどう貢献するか

今のチームには僕は途中からJOINしているのと、外側から関わってきたという背景があります。メンバーの大半は長く同じチームに在籍しているひとが多いです。

チームを底上げすること、自動化まわりの技術をリードできること、仕組みの変更を得意としていることから、1つの技術開発をどっぷりやるというよりは、全体最適のための改善をリードしていく立場をやりたいです。

途中からJOINした自分だから見えることがあるので、現在の自分の案件を持ちつつ、広い視点を持って、細かい改善から大きな仕組み変更まで、できるだけ多くやっていきたいです。

ただし、改善というのは、「したらうれしいけどしなくてもしなない」こと。自分の案件も持っていて改善だけやっていればいいわけではないので、コミットが難しいのが難点。

いかに日頃の業務スピードをあげて、改善に時間が割けるかが鍵だと思います。

やりたいと思ってる改善は以下

  • MS WORDの撤廃、すべてのドキュメントをgit差分管理可能な状態にする
  • 上記のためドキュメントCI環境構築
  • configのgit管理と、適用自動化
  • ドキュメント開発へMRによるレビュープロセス導入
  • 開発環境のモニタリングとインシデント事前予防

まとめ

オープンな技術で、会社を超えて広い世界で評価される技術をつけることも大切ですし、今後発信も行っていきたいですが、今自分が働いてるチーム内という小さな世界でも自分の立ち位置、価値、そしてどう貢献していくかを考え、周囲にコミットしていくことも大切だと思いやってみました。頑張るぞ!

*1:あなたいつその情報仕入れてるの、みたいな物量と深さのあるネタを週一でメーリスに投げてくるひとがいる

「エンジニアのための文章術再入門講座」を読んでドキュメント作成スキルの振り返りをする

はじめに

良いドキュメントを書くことはエンジニアのたしなみ。ということで定期的に自身のドキュメントスキルの見直しを行っています。

エンジニアのための文章術再入門講座

エンジニアのための文章術再入門講座

ドキュメントといえば結城先生の数学文章作法もおすすめ。

で、この"エンジニアのための文章術再入門講座"なんですが、各章ごとにエッセンスを紹介して、そのあと具体例を用いて悪い文章を良い文章に直す、というスタイルで進んでいきます。ただ、この例がかなり自分にとってはしっくりこず、本当にこんなドキュメントわざわざ書くやつおるんかいな、と思うシーンがほとんどで、僕はエンジニアのはずなのにおかしいなぁと思ってしまいました。

とはいえ、書いてある観点そのものは正しいと思うので、その点にしぼって振り返りをしてみます。

エンジニアにとってのドキュメント

その前に、エンジニアにとってなぜドキュメントスキルが必要か、ということを再認識しておきましょう。

本書でも一章で、ドキュメントはエンジニアのスキルを表すということが言及されていますが、信頼できる文章を書くことで技術的にも期待されるという面は確かにあると思います。

私は本書の例にあるようにお客様にシステムを提案するドキュメントを書くことも、経営層に投資対象を選択してもらうためのドキュメントを書くこともありません。

今の私が仕事でドキュメントを書くシーンは

  • ツールやコードのREADME、MergeRequestでの仕様説明
  • チームメンバーや後輩への業務指示
  • チーム内で遵守すべき共通ルール
  • ナレッジ(技術的知見)の共有
  • 業務上不明点の相談、報告
  • 業務進捗報告
  • イベント参加報告

ぐらいでしょうか。どれもたいしたことないように思えますが、なるべく一発で相手に伝わるドキュメントを書くスキルは重要だと以前より考え、ブログでのアウトプットを続けているのもその一環です。(時間に余裕が無い時スピード重視で雑なままつきとばしてしまうことが最近あって、反省。。。)

チーム内でもドキュメントに対するこだわりは強いのですが、実力はまだついていないようで、まだ他者に褒められるまではいたってないので今後も精進。。。

ドキュメントを書く時の心がけ

本書第2章で語られている以下の2点は正しいと思います。

ルール① 目的にフォーカスする ルール② 相手にフォーカスする

結城先生も「読者のことを考える」だけをひたすら言い続けた本を書いたわけですが、その読者がどういう知識レベルで、どういう目的で読むかを考えることが第一に大切なことだと思います。

プレゼンのときに「対象は誰で」「知識レベルはどれぐらいで」「何を持って帰ってもらうことが目的なの」ということを考えますが、それと同じですね。

論点を絞る

本書第3章では、伝えたいことを1つがテーマです。本筋に余計なことが書かれていると気が散りますよね。

余談ですが、余談ですがで本筋を見出しまくったココイチ好きすぎな記事を昨日読んで、なるほどカレーが食べたくなっちゃうなーと思いました。余談ですが。

www.mikinote.com

本書まとめでは「論点を絞る」ことに関するチェックポイントが5つもあってなかなか絞りきれないと感じました。

論理的記述力

4章、主張をしたら根拠を述べる。

まぁ、そうねって感じですね。

ちなみにまとめで5つのチェックポイントがあるわけですが、5つめの受け身表現や稚拙表現を使わない、がカテゴライズされてるのが謎です。この主張自体は正しいのですが、論理性による文章の信頼性担保のついでに、受け身表現も信頼度減るよ、稚拙表現(これはこれでまた曖昧な表現ですが)も信頼度減るよ、だからやめようね、のついで感があります。

構造化力

5章、同じグループをまとめたり、同じ階層ではレベルを揃えるとのこと。これはとても重要ですね。

箇条書きでよくやりがちなのは、粒度が揃っていなかったり、論理展開を並べてしまったりする場合があります。

# 私とカレーについて
* カレーが好き
* キーマカレーが好き
* 週末はよくカレー作りをする

おいおいカレーとキーマカレーは粒度が違うやないかい、カレーの好みと、カレーをどう好きかもまた粒度が違うやないかいってなりますよね。

# 私とカレー
* カレーはおいしい
* カレーを作ってみようと思った
* カレーエンジニアに

まぁそんな流れでカレーエンジニア(ってなんだよ)になったのかなーってのはなんとなくわかるけど、思考の流れや論理展開を箇条書きにするのも好ましくないと思います。伝わるけどね。

平易表現力

本書第6章です。

難しい用語、専門的な用語、自分やチームの人しかわからない言葉は、言い換えて表現する ただし、文章に前修飾すると分かり難いので、脚注やカッコを使う

"一言で言う「結論」"で「ただし」と足されているところがしっくりきませんが、使う用語は読者が理解できるものしようというのは正しいと思います。

これは冒頭で述べた「読者の知識レベルを考える」でカバーできる範囲だと思います。

正確表現力

7章です。

自分が知っていることを省略しない、あくまで相手の知識や理解をベースに書く 主語や主体は明確に書く 曖昧な表現や無意味な表現をしない

3点目の曖昧な表現や無意味な表現がとってもブーメランになってる気がしますが、暗黙的な理解を省略してしまうことはあると思うので、前提が相手にはわかるかな?という視点は大切かと思います。

あとここに関連するか微妙ですが、略語を使わないということも大事ですね。(略語も省略といえばそうなので) 少なくとも1回目は正式名称で述べ、以降略するとか。ついついチーム内への提案ドキュメントにcapistranocapiと書いてしまって最近指摘されました。capiって言うもん。ごめんなさい。

A remote server automation and deployment tool written in Ruby.

capiはいいぞ。

短文表現力

8章

無駄な文章をそぎ落とす 図解や記号化を行い、文章を画像として扱う 短くするための言い換えを使う

!? って感じのまとめですが、できるだけ短くしようね、ということは納得します。

論理展開を→を使って省略するということが主張のようですが、まぁ好みの問題かなと思います。

体現止めにしてブロックにしてそれを矢印で遷移させるのはプレゼンの領域でしょう。

感情・心理利用力

相手の感情に訴えるなど、心理面のアプローチをドキュメントに埋め込む 複数案から選ばせることで、こちらの意図した方向に誘導するなどの技術を駆使する

上記の結論を添削するなら、本書はドキュメントに関する指摘をしているので"ドキュメントに"埋め込む は冗長。

意図した方向に誘導する"など" という曖昧な表現は排除すべきですね。

で、ここにきて感情論かよ、って思いそうになりますが、これは「相手の気持ちを考える」ということなので、とても良いことです。つまり提案を受ける側の選びやすい形にしてあげる、と捉えることができます。

まぁなんか相手を褒めるとかも書いてありますが、うん、まぁ、そうね、普段のコミュニケーションとしては大事です。

この章、言ってることは間違ってはいないのですが、ドキュメントの技術的な校正を考えるなら除外すべき章だと思いました。もう少し大きな枠組みで、チームで働くときに気をつけるべきメンバーへの働きかけ方、という範囲で述べられることかなと思いました。

フレームワーク

相手と目的によってフレームワークを用いましょうという話。そういうものがあるなら使えると思いました。ここはテクニックではないですね。

おわりに

あらためて振り返りましたが、ドキュメントの目的を考える、読者の知識レベルを考えるという2点はやはり欠かせません。

その上で本書を読んであらためて気をつけたいことは

  • 論点を絞ること
  • 構造化し、箇条書きは粒度を揃えること
  • 表記ゆれ、誤字、省略を避けること

を守れば良いドキュメントは書けると思いました。

最後に思い出したようにひとつ。僕がドキュメントへのこだわりが強いのは以下の記事であるように引き継ぎが大嫌いだからなんですね。正確には無茶振りな引き継ぎでつらい目にあったからなんですが。過去のこういう記事を書いていました。

take-she12.hatenablog.com

良いドキュメントはエンジニアのたしなみ。今後もソースコードと同じぐらいドキュメント作成能力も鍛えていきましょう。

ようやくSRE本を読み終わりました

はじめに

読み終わりました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

英語の原著が出た時点でkindleで購入していたにも関わらず読み通せなくて、その後英語版は無料公開されました。

Google - Site Reliability Engineering

ほどなくして翻訳版が出て、読まないわけにはいくまいと購入。2ヶ月ほどずっとリュックやバッグにいれて持ち歩いていました。重かった。。。

SRE、信頼性エンジニアはGoogleで古くからあり、日本でもメルカリをはじめ、現在は様々な企業でSREポジションが存在します。(言葉だけ広がって流行っているとも、見える。)

GoogleのSREにはなれなくても、SREのような考え方を大事にする場所で働きたいと思います。せっかく読み通したので振り返りをしておきましょう!

まず、Google SREのコアな考え方は9章の第2部までに集中しています。まずはここをおさらい。

原則

エラーバジェット

Google SREの中でも大切な考え方の1つ。単純に、サービスが保証する信頼性目標(SLO: Service Level Objectives)を超えているのであれば新機能のリリースができ、下回っている場合は新たなリリースができないことを開発・運用双方で合意しています。

これによって新たなリリースという障害リスクを抑制することと、信頼性向上のための施策を行うことができます。

SLO、SLA、名前はあれどそれを明確に顧客と約束したり、計測して結果を振り返ったりすることは非常に難しい。そして計測しなければこのエラーバジェットによるリリース制約はできません。

SLOの指標

では何を指標にし、どう収集すればいいのでしょうか。

これは多すぎてもいけないし、見当違いのものでもよくなく、これを決めるのはかなり経験が必要ではないかと思いました。

また、「最初から完璧でなくてもよい」とある通り、継続的な見直し、修正が基本的な考え方なんでしょう。

トイル

これもSRE本での重要な考え方の1つ。本書によれば、

プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。(p51)

ここでもっとも重要なことは"作業量がサービスの成長に比例する"ということでしょう。単純な手作業だとしてもサービスの成長=機能追加の数が増えるだけで、その作業は指数的に増えるかもしれません。

本書34章まとめで、SREの進化を航空業界に例える例がありますが、まさに「サービスが数百、数万のオーダーで成長しても、"同じ人数"で信頼性を維持することが、SREでもっとも重要な考え方の1つだと思います。そのためにトイルは絶対撲滅しなければなりません。

SREの業務

SREの業務はおおよそ以下の4つに分類できます。

  • ソフトウェアエンジニアリング
  • システムエンジニアリング
    • システムの設定変更、システムに関するドキュメント作成。1回の作業で改善が持続するようなもの。
  • トイル
    • サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするもの
  • オーバーヘッド
    • サービスを稼働させることに直結していない管理的な作業。採用、人事、ミーティング、バグ整理、レビュー、自己評価、トレーニング

なるほどこの4分割は、現状の自分の業務でも納得できます。(もっとも、これらに含まれない本当にやりたくない仕事もたまにあるが)

トイルを減らし、エンジニアリングの割合を増やすこと、これがSREがいる組織と、従来のDev & Opsが分かれている組織との違いですね。

モニタリング

レイテンシ、トラフィック、エラー、サチュレーションが4大シグナル。モニタリングの設計をした経験がないので、今後やる場面になったときにもう一度読み返したい。

自動化と自律性

7章、Googleにおける自動化の進化ですが、ちょっと内容かわかりづらいんですよね。

自動化の進化は以下のような経過を辿る。

  1. 自動化以前
  2. 外部でメンテナンスされるシステム固有の自動化
  3. 外部でメンテナンスされる汎用の自動化
  4. 内部でメンテナンスされる汎用の自動化
  5. システムが自動化を必要としない

最終的には5、つまりシステムが自律的に問題を解決する(自動化した何らかの解決手段を必要としない)ことを理想としています。現実的に身の回りでは2か、頑張って3ぐらいですね。。。

例えば、今の職場では共通のSSL-VPN接続端末があって、そこを経由して検証環境につなぐのですが、最初は各クライアントで使うための自動接続スクリプトを作ったんですね。(2) それを共通基盤として使うようになって、(3) 切断を検知して(よく切れる)自動再接続するようにしました。(4) この順序は正しいですね。

リリースエンジニアリング

いわゆるCI/CDと言われている領域に近い話ですね。

哲学として高速性、密封ビルド(一貫性と再現性の保証)があげられています。

これは継続的ビルドとデプロイメントで紹介されているビルドの速度と、パッケージ化ですね。ubuntu系のdebrhel系のrpmのようなパッケージシステムによって一貫性と再現性を保証します。

アプリケーションやインフラのソースコード管理、そしてビルド、デプロイの自動化は最近では当たり前のようにされるようになったと思いますが、設定管理はどうでしょうか。通常、ソースコード管理で管理しない、いわゆるconfigのようなところです。

本書でもバイナリ(と呼ぶ、アプリケーションをパッケージとしてビルドしたもの)と設定は別管理をするが、フラグを使ってひも付ける例があげられていました。例えばansibleのような構成管理のタグとrpmのバージョニングを合わせて管理するのがベストといえそうです。

実践編

ここからは実践編で、理論というよりはポエムとなります。googleの社内ツールの話は理解が難しかったのであまり深く読んでません。オンコール対応も(SREとしては重要な話ですが)現職ではそのポジションにないので飛ばしました。

中でも面白かった章を紹介します。

トラブルシューティング

トラブルシューティングって、みなさんどうやって習得しましたか。ぼくはいきなり障害番号投げつけられて「これ見て」からはじめました。ひどいよね。

今思えば当たり前のことですが、

  • 一般的なトラブルシューティング手法の理解(すなわち、特定のシステム知識とは関係ない)
  • システムに関するしっかりとした知識

この2種類あるが、それよりは、本来そのシステムのあるべき姿を知っていることが大事だと言います。本当にそうだと思います。

システムの本来の動きも知らない、一般的なトラブルシューティング手法も知らない、特定のシステム固有の話も知らない状態で振るなんて悪手でしかないので絶対に自分より下にはそんな思いをさせたくない。この章を2年前に読みたかった。

問題のレポート、トリアージ(システムがその環境下でできる限りうまく動作するようにすること、すなわち暫定対処や復旧のこと)、検証、診断、テスト/対処という流れでトラブル対応していくことになります。最初はこの流れすら知らなかった。のちに仮説/検証のサイクルで詰めていくことが大事と自ら学んだ。悪くない経験とはいえ、遠回りしてしまった。

この章はトラブルシューティング初心者にはかなりおすすめですね。

ポストモーテム

ポストモーテムも、SREとしてかなり重要なことですね。

しばしばインシデントはドキュメント化されるというよりは、報告が義務付けられるので、何らかの形で残ってはいるのですが、それを「次への学び」に活かすという視点での活用は今の職場にはないところです。

ポストモーテムで批判を行ってはいけないことは繰り返し述べられています。

「今月のポストモーテム」や「ポストモーテムニュースグループ」「ポストモーテム読書会」はすごいいいですよね。個人的にはやってみたいな、今のチームでできないか考えてみたいと思います。ちょうど勉強会やってるし。

データの完全性

特にバックアップとアーカイブの違いについてが面白かったです。アーカイブは完全に保管するものの、リカバリ2時間がかかってもさほど問題はないでしょう。逆にバックアップはリカバリが素早くできないのであれば意味がありません。ユーザから見て対象のデータが長期にわたって使えないのであればバックアップがあっても無意味です。それが「データの完全性は手段であり、目標とするのはデータの可用性である(p363)」ということでしょう。

そしてやはり重要な学びは"多層防御"でしょう。複数のレイヤーで可用性を確保しておかねばなりません。

そして必ずリカバリの検証をすること。「バックアップできてるはず」「リカバリできるはず」ではいけません。"願望は戦略にあらず(p387)"の通りです。

管理

4章ではSREの後継の育成や、割り込みと対処、SREチームと他の開発チームとのコミュニケーションなど、より人間的な面での実践アプローチが語られています。これも今後機会があったときに読み返したいです。

おわりに

何とか通読したものの、「ウォーこれはこういうことだったのかーこの考え方は大事にしよー!」ってものと、あまりピンとこなかったものがありました。自分自身の経験に合わせて再度読み返すときっと新しい気づきがあるでしょう。システムの信頼性に関することなら、何かしらのヒントがこの本にあるはずなので、壁にぶちあたったときに手を伸ばせるように手元に置いておきたい本です。

私個人としてもSREというポジションになりたいと思っているので、読み通したかった本がちゃんと読めて、こうやってブログで振り返れてよかったです。

直近の業務で活かすことといえば、インシデントを一手に受けているので、トラブルシューティングの一般化を後輩に伝えていくこと、勉強会を主催しているのでポストモーテム読書会はやりたいということと、モニタリングについて自分自身で設計したことがないので何かしらでやってみたいです。

さて、次は同じくUberのSREが執筆した「プロダクションレディマイクロサービス」も買ったので、読んでブログ書きたいと思います。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

転職活動をしてみて思うことや、職務経歴書のgithub公開

はじめに

1ヶ月ほど前、この記事で「キャリアを次に進めます」とある通り、Wantedly経由でいくつか企業に訪問している。

take-she12.hatenablog.com

モチベーションとしては、自分の市場価値を確認したいということと、もし可能であれば環境を変えたいということ。今の職場・仕事内容に不満はないので、「今すぐ転職したい!」ような積極的な転職活動ではなく、情報収集をかねてやってみてるレベルである。

年度内(2018年3月まで)に何かしらの結論を出したい(するなら内定、しないならしないと自分の中で決める)と思ってる程度にはのんびりな活動ではあるが、いくつか気づきや学びがあったので書き記しておく。

カジュアル面談

wantedlyでいうところの「カジュアル面談」は、正式は採用面接ではなく、ラフに情報交換をしましょう、まずは遊びにきて少し話しましょうよ、というもの。プロフィールをそこそこ充実させておけば向こうからスカウトがぼちぼちくる。もちろん自分から話を聞きに行きたい!と申し出ることもできる。

約2ヶ月ほどのスパンで計5社訪問した。途中現業が忙しくなったこともあって期間を開けた。だいたい週に1社ぐらいが限界。あんまり早退しすぎると現職の人間に怪しまれるしね。

だいたい対応してくれるのは人事か、エンジニア系の管理職、あるいはその両方。会社によってはエンジニアを呼んで話しをしてくれるところもあり、スカウトを送ってくるほどの会社はわりと熱心に相手をしてくれる。(今すぐ面接を受ける意志がないにもかかわらず!)

だいたい1時間程度なんだけど、ここの内容は企業によって結構違う。会社側から一方的に説明して、何か質問ある?というところもあれば、面接じゃないけれど面接みたいに、どういうことがしたいですか?と聞いてくるところもある。

いずれにしても、その会社の事業領域や強みを、1:1で聞けるというのは非常にありがたいし、自分が活躍できるポジションがあるかないかはだいたいわかるので、可能な限り気になる企業とは話したほうがいいと思った。

ちなみにこれは余談で、今日受けた企業はマッチングが成立しないにもかかわらず、キャリアに関するあまりあるアドバイスをくれて、本当に良い方でした。本当は内容をブログに書こうと思ったのだけれど、会社名を伏せると何も言えなくなってしまった。笑

自分のキャリアのためになる仕事をする

転職活動をして、自分のやりたいこと、これまでやってきたことを、面談で話すということを経験すると、今の職場でも、自分のキャリアにプラスになることをしよう、という気持ちになる。

転職する気がなくても、転職活動はやるだけプラスというのはこの点にあると思う。今給料をもらいながら、その時間で何をするのか、が明確になった気がする。

職務経歴書

以下の記事の影響で思い切ってgithub職務経歴書をアップした。

qiita.com

職務経歴書はこちら。

github.com

現職の人間が見れば一発でわかるが、一応具体的な会社名は伏せた。

定期的にメンテナンスをしていきたいと思う。今までやってきたこと、今やってきたこと、自分が何をやりたいと思っているかを、都度文章化することは大切だと思う。

おわりに

まだカジュアル面談をしただけで、転職活動しています!なんて大げさだが、少なからずメリットはあるので、やっぱり定期的に社外のひとと自分のキャリアについて話す機会というのは今後も持ち続けたいと思います。

GCPのコンピューティングサービスの料金をざっくり確認する

はじめに

カレー好きなエンジニア、たけしです。ついついGCPでがっつりカレーパーティに申し込んでしまったのですがGCPを使ったことがありません!

topgate.connpass.com

やばくない?何だこのイベント!これを機に俺もGCP好きのカレーエンジニアになるぞオォォォとなりました。

真面目な理由としては、今後仕事でクラウドを"使う側"に立つ可能性があり、AWSだけではなく、GCPやAzureで何ができるか、何が違うのかは把握する必要があると思っていること。コンテナオーケストレーションのKubernetesを使ってみたいことがあります。

で、まずは料金からです。

料金体系

公式の日本語サイトが充実しています。

cloud.google.com

料金計算ツールもあるので合わせて見ていきましょう。

cloud.google.com

App Engine(GAE)

アプリケーションを載せることができる、PaaSです。

cloud.google.com

言語はNode.js、JavaRubyC#、Go、PythonPHPに対応。トラフィック分割やアプリケーションのバージョニングなど、リリースに関する仕組みは気になりますね。

Herokuに似たようなサービスです。

気になるお値段は?

  • インスタンスのクラスによって、0.05〜0.30 USD / hour のようです。
  • 起動時には15分間の起動時間が加算されます。つまり最低課金料金が15分間ということですね。
  • Google Cloud Databaseは無料枠あり。1日1GBのデータ保存まで。

料金計算ツールを使ってみました。

Outgoing Network Traffic: 1 GB
Cloud Storage: 10 GB
$0.13

1ヶ月です。適当にネットワークとcloud storageを入れてみましたが、app-engineのインスタンスには課金は発生しないようですね。search apiなど他のサービスを呼んだり、トラヒックを使うと課金されていくようです。

Compute Engine(GCE)

cloud.google.com

EC2と同等のものですね。

なんとf1-microだと料金はかからない!あとは基本的にはフレーバーのレベルによって変わるみたいです。

f1-microで1ヶ月使った場合

730 total hours per month
VM class: regular
Instance type: f1-micro
Region: Iowa
Sustained Use Discount: 30%  
?
Effective Hourly Rate: $0.0053
Estimated Component Cost: $3.88 per 1 month

わずか3.88ドル。永続ストレージ30GBをつけても

Storage: 30 GB
$1.20

合計5ドルです。めちゃくちゃ安いですね。

Container Engine(GKE)

Google Container Engine ドキュメント  |  Container Engine  |  Google Cloud Platform

ECSと同等のサービス。

クラスタ内のノード数が5までなら無料なんですね!クラスタのノードにはGCEを利用するようで、GCEの料金がそのまま加算されます。

6ノード以上だと、アイオワでは1ヶ月

6 ノード以上    標準クラスタ  $109.50

結構かかりますね。

Container Registry

cloud.google.com

DocukerHubのような、Container Registryサービスは、StorageとNetworkの料金のみしかかからないようです。

Google Container Registry では Docker イメージが使用した Google Cloud Storage とネットワーク出力に対してのみ料金が発生します。詳しくは、料金ガイドをご覧ください。

Cloud Functions

cloud.google.com

lambdaに代表される、Function as a Serviceですね。

こちらも無料枠が用意されてます。試すだけならできそうですね!

  • 呼び出し
無料試用枠 無料枠を超えた料金(単価) 課金単位
200 万回 $0.40 呼び出し 100 万回あたり
  • コンピューティング時間
無料試用枠 無料枠を超えた料金(単価) 課金単位
400,000 GB 秒 $0.0000025 GB 秒単位
200,000 GHz 秒 $0.0000100 GHz 秒単位
  • 送信データ(下り)
無料試用枠 無料枠を超えた料金(単価) 課金単位
5GB $0.12 GB 単位
  • 受信データ(上り)
無料試用枠 無料枠を超えた料金(単価) 課金単位
無制限 無料 GB 単位
  • 同じリージョン内の Google API への送信データ
無料試用枠 無料枠を超えた料金(単価) 課金単位
無制限 無料 GB 単位

結構安い気がする。何個ノード?を立てるかは関係ないのか。

おわりに

ざっくりComputeサービスの料金を見てみました。StorageやNetworkの料金が関係してくるので一概には言えませんが、個人が簡単に試してすぐ消す分にはCloud Funtion、f1-microでのGCE/CKEはそんなに大金かけずに使えそうです。

次回はTerraformを使って実際にインスタンスを作ってみたいと思います。

「友人たちのためのブラウザ」Vivaldiのショートカット調べてみる

はじめに

vivaldi使ってますか?ぼくは毎日楽しいvivaldiライフを送っています!Tシャツ買っちゃいました!

steers.jp

以前記事も書きました。

take-she12.hatenablog.com

長く使っているのにもかかわらず、ショートカット全然使いこなしていません。今から覚えよう!のモチベーションで記事を書き始めています。一緒に触っていきましょう。

チートシートを見る

まずcommand + F1でチートシートを眺めていきます。

ウインドウ

  • Windowを閉じる、Command + Space + W は押しづらいですね。使いそうだけど。
  • Command + E、もしくはF2のクイックコマンドはまず覚えたい
  • Command + Shift + Bでブックマークが出たり消えたりする。知らなかった。

表示

  • Command + / でアドレスバー。検索が早くなりそう。

  • Command + F11、UI切り替え。タブやアドレスバーなどがなくなってWeb画面だけになります。

  • 拡大/縮小 拡大がCommand + ^、縮小がCommand + -でした。

  • F4でパネル

  • F7でパネルにフォーカスを移す

  • Command + Control + 何かで履歴やブックマークをだせる

タブ

  • Command + Tで新しいタブ
  • Command + Wでタブを閉じる。なんでWなんだろう。
  • タイルにしたり縦にするCommand + F6-F9は解除しか効かなかった

表示

  • Command + D ブックマークの作成​

Macのショートカットキー記号

そもそものことを言いますとMacのあのマークが覚えづらくて全然ショートカットキー覚えられないんですよ。Commandのアレはキーボードに書いてますけど、家マーク、ハット(^)、右下がりのエスカレーター、、、これのいい覚え方はないんですかね。

support.apple.com

もう2年Mac使ってるやつのセリフじゃないな。。。

その他カスタマイズ

せっかくなのでこれを機会に設定見直しました。 * アドレスバーに検索欄を表示、をオフ(アドレスバーで検索できるので不要) * マウスジェスチャー ALTと一緒にジェスチャー有効

を変更しました。

おわりに

大好きなvivaldi、たまにタイルにするぐらいしか特有の機能使っていないですが、ショートカットキーこまめに確認して少しずつ覚えようと思います。