大学中退して現職SRE
人生いろいろあるけど元気に生きていこうな！
要約
- 大学卒業するのめちゃめちゃえらいけど、中退がえらくないわけじゃないよ、がんばって
- ちゃんと生きてお仕事してます
- SREっていうちょっとおもしろい座組の組織にいます
- 3000文字くらいです
この記事は公立はこだて未来大学AdventCalendar2020 その2 14日目の記事になります。
元公立はこだて未来大学複雑コースの @Tkon_sec です。
temama (@Tkon_sec) | Twitter
数学について行けず中退しました。
半年前にThinkPad X390を買ったのですが、色々合って5回ほどメインボードを交換してもらいました。環境失うことに何も抵抗がなくなった。
大学中退のその後（ご参考までに）
大学を中退する方法についてはご存知だと思うので割愛
18年後期から休学し、19年前期をもって退学、就職のため関東へ引っ越して現職場へ秋入社して社会人2年目に入ったところです。
18年前期には既にほぼ大学を諦め、アルバイトをしつつ遊び歩きました。人生20年で一番楽しかった。
18年後期に休学すると共に、19年春に就職を目指してふわっと就活をはじめました。
ふわふわ就活の内容は以下です
結果19年春に就職することは叶わず、函館でアルバイトしつつ遊んで暮らす日々を継続しました。正直楽しかったのであんまり苦でもなかったです。
そもそも僕はエントリーシートや応募用紙等を書くのが特に苦手かつ嫌いな人間で、かつ嫌いなことを絶対やりたくない人間なのでまともにエントリーシートを出せた企業はそこまでありません。中には会社の人からぜひ申し込んでねって直接言われてぜひぜひ〜って答えたのに最後までエントリーシートを送れなかった企業もあります、ごめんなさい
そんな中とある会社のありえん楽なエントリーフォームがあって、深夜テンションか何かでほぼ文章を書かずに送ったらインターンに通り、そのまま採用して頂けました。
名前を面白法人カヤックと言います。
いま自分が社員として働けているのが不思議なくらいふわっとした採用で未だに困惑してはいるのですが、きっと運が良かったのと評価されるものがあったんだなぁ…というふわふわしてる気持ちで働いています。
一応言っておくと誰でも採用してくれる場所ってわけじゃないです（当然）、ちゃんと採用基準とか色々ある上で採用して頂けているので、ご縁があったことに感謝しております。
いまちゃんと中退を考えている方々は僕よりは固いものを持っていると思うので、それくらいの固さならなんだかんだ生きていけると思うので頑張ってほしいです。
中退と聞くとどうしても人生のレールから脱線した身分のように思えて病んでくるんですが（僕は病んだ）、大学をちゃんと卒業した方々は努力家ですごい偉いのは間違いないけど、だからといって中退した人間が底辺かと言われると絶対そうじゃないと僕は思うので、我を見失わずに生きていきましょう。
言うて病み始めている人にはなかなか周りの言葉は刺さらないので、良い方向に進むことを願っております。
現職、SREというお仕事について
さてそんなふわふわした経緯で働いているのですが、現在の私の所属はSREといいます。
きっと聞き馴染みが無い方の方が多いと思います。略さない名称は「Site Reliability Engeneering」で、日本語でいうと「サイト信頼性エンジニアリング」です。
Googleが提唱するエンジニアの分類で、詳しい説明はこの本に全部乗っています。というか現状SREの細かい定義その他の全ての情報源はこの本です。
O'Reilly Japan - SRE サイトリライアビリティエンジニアリング
何をするかというと、サイト（あるいはサービス）の信頼性を高めるための開発作業を行うエンジニアです。
信頼性とは何かというと、例えばそのサービスがいつでも使えること、サービスから返ってくる結果が正しいことなど、サービスが正常な状態を担保する、というような内容です。
例を上げると、Google検索が頻繁に利用できなくなったり、検索結果が望ましいものでは無かった場合はGoogle検索の信頼性は下がった状態と言えます。
これを避けるためのエンジニアリングとして、わかりやすいものとしてはインフラの適切な増強作業があります。
大抵のサービスが利用不能になる原因の多くはインフラ周りなことが多く、SREはインフラエンジニアと間違えられがちではあります。
しかし実際には、SREは信頼性を上げるためであれば様々なレイヤーを渡り歩くことがあります。ボトルネックになるのがサーバーサイドのアプリケーションであればそれを直し、フロントにあるならフロントを直し。
しかしこれでは後手後手に周ることになりますし、本来はそれぞれのアプリを開発している人が対応すべき問題です。
そこでSREはいくつかのアプローチを取ります。
一つは機能開発のペースを落とさせることです。新機能の開発を止め、新たなデプロイを止めればアプリに起因する問題の発生率は下がります。空いた開発者の作業時間で残っている問題を洗い出し、解決させることも出来ます。
他には、アプリ開発の中で不具合を入れないための仕組み、ツール等を作ることです。
テストを回すのがわかりやすいですね。CircleCIや、最近ではGitHub Actionsなんかを活用しています。アプリの開発フローにテストが無い、あるいは不十分であれば追加する作業またはツールの作成を請け負います。
また、デプロイの手順や手法についても信頼性を損なわない手段があれば取り入れるなどします
このような作業を行うことで、サービスは不具合発生の割合が下がり、緊急対応に割くリソースは減り、アプリの開発者はより機能の開発に集中できるようになります。
特に不具合時の緊急対応はSREが行うことが多いため、緊急対応が減ることでSREが緊急対応以外に使えるリソースが増えます。この時間で信頼性を上げるためのツールを作成するなどの前向きな作業が出来るようになります。
エンジニアの皆様は信じられるのは公式ドキュメントと中の人とソースコードだけ、ということをご存知だと思いますので、SREについて気になった方は是非オライリーのSRE本を読んで頂ければと思います。僕がどれだけテキトーなことを言っているかわかると思いますので…。
ちなみに僕の話ですが、今年はAmazonLinux1がEoLを迎えるとのことでとにかく様々なアプリを別の場所に載せ替える仕事などをしています。楽しい。
SRE感はまだあまりないです、きっと来年からもっと楽しくなってくると思います。
おわりに
カヤックでもアドベントカレンダーの記事を順次公開しています、先輩社員のフロント/サーバーサイド/インフラ/解析など様々な分野のありえん強い話がたくさん読めるので、気になった方はこちらも是非よろしくお願いします。
Tech KAYAC Advent Calendar 2020 - KAYAC engineers' blog
あと大学ちゃんと卒業しようとして頑張っている方々、すっごい偉い。本当に尊敬してます。
