インフラエンジニアからSREになって一週間が経ちました

こんにちは、無能です。
割と自分でも調べていたけど、SREという職をしている人たちの記録があまり就業前に見つからなくてイメージ沸かなかったのでここに書き留めます。
初手はインターミッションとして、あんまり業務的には関わらない部分として入れているので別職種の方でも楽しめる程度にします。

私はこんな人間です

ビンテージ屋さん歴3から4年くらい
インフラエンジニア歴1年

元々コンピュータは好きなので、小学6年生くらいからレンタルサーバでホームページ作ったり、中学から自作PCとハンダコテ使って修理したり、cgi本学んで掲示版をレンタルサーバで立てたりしてました。

情報系の高校卒でしたが、仙台で当時いわゆる情報通信業、IT系の求人があまり無く本当にこれ仕事としてできるんか？と思っていたのでフラフラ生きてました。
今は仕事で今月から都民になりました。
ビンテージ屋さんをやっていたのは当時の社長に働いてみる？って言われてバイトし始めてその後に正社員になりました。

はじめに : 駆け抜けた一週間

他県に移り、先月12月27日までと駆け抜けるように就業していたので色々な脳みその切り替えが必要なこともありそれで精一杯だった部分があります。
23歳でこの機会をいただいたということもあり全力疾走していました。

内見もせずに家を決めましたが、職場からある程度近いことと家の近くに以下があるのは強いです

100円均
安い中華屋
個人店のリサイクルショップ

家ついたときに、まさかのシーリングライトが無く引っ越してきてから1~2日間くらい電気無い生活していましたが割と苦しくないです。明るい時間に起きて暗い時間に寝るっていうむちゃくちゃ良い体内時計リセットになります。

MacOSとMac US配列に不慣れな日々

現在絶賛GNU/Linux, BSDユーザな私ですがここが不安点でした。
ただ、リーナスも絶賛のM1/2/3チップのMacはつよつよです。

.zsh自体も初めてでしたが、基本bashの上位互換にあたるのであまり困ることはないですがデフォルトの$PS1、プロンプト表示が必要最低限でカラースキーマ設定も入っていないので自分のArtix Linuxに合わせました

必要最低限の.vimrcの設定したくらいでしょうか。

MacUS配列！

コンパクトなMacBookのJIS配列だとキー自体がむちゃくちゃ凝縮されて不安だったのと、半角/全角キーがMacBookのJISでは同じ場所に存在しないのでUS配列にしましたがやっぱり普段JIS使っていると慣れるの大変ですね。
ここに関しては外部キーボード結局使えば解消出来る問題なので、特にあとから流石に堪らなくなればどうにでもなります。

ThinkPad キーボードを買っておかないとって前のブログで言っていたって・・・？それは幻覚ですよ・・・。

なんかQiitaで見た記事書いている人がいる・・・

Qiitaで記事書いていた人が会社内にいると、相手は自分のこと知らないのに自分は一方的に記事を読んでいたので一方通行オフ会みたいな感覚です。

Qiitaの名前の由来とか、アイコンの由来とか聞くとそんな背景あったのか・・・と思う日々は面白いです。

運用フロー、業務フローとか諸々

これ、それぞれの組織によって異なるのである程度チャットとかにある流れを汲み取って色々なパーツとして認識して頭の中でイメージして組み合わせていく必要がありました。

同じソフトウェアでも使い方が変わる様に、Nginxはウェブサーバとしても使えるしプロキシサーバとしても機能したりするように業務に関してもどんなフローで毎日のタスクをみんなこなしているんだろう？というイメージ作りはなかなか大変な部分はありますがなんとか優しいパイセンのおかげで少しずつ理解してこれています。
人に感謝感激雨あられ。

日々のメモは毎日取ろう

vimを普段から使っている民なので、Markdown形式でメモしているとあとで日報書くときにも便利だし、しょうもないメモも割とあとからになって必要になってきたりする事多々あるので何から書き出せば良いんだろう？ということに関しては会議中に見ていたURLをメモ書きに貼っておくだけでも良いかもしれません。

社内セキュリティでターミナル上からだけだと認証ナシで見れない場合意味無いですが、自分で作ったURLからタイトル取得し、Markdown形式で出力するツールは業務中にも役に立ったので宣伝しておきます。
GitHub - haturatu/ght: go-http-title Get website title

ぶっちゃけ最初に出来ることは特にないが組織単位のIaC化の良さ

日々学びがあるので、非常に楽しい日々です。
特にインフラエンジニアとの大きな違いはよりクラウドライクな運用を想定しているので、より全体アーキテクチャのイメージが付きづらいところがありますがもちろん元々の考え方が役に立つコトは多々あります。
IaC化なども難しい部分はありますが、完全WebGUI上のみで逐一全ての必要情報を見なければいけないという事よりもコード管理されていとどんな構成で立ち上げるんだろう？というものがテキストベースで確認出来るので逆に楽であるメリットは多いにあります。

デメリットは？

これというデメリットはあまりないのかな、という肌感ですがしょっぱなでの運用イメージを掴む事が難しいのであとから入ったとしてのSREチームの運用する人も助かるように業務的にはドキュメントを自分が補填していくことは行っていきたいなと思っています。

GoogleのSREのドキュメントでもあるように、少数精鋭部隊として立ち回ることが推奨されていますがその分チームメンバーのワークロードは増えてしまう部分があるのかなと思うところがあるのでなかなかドキュメント整備が完全化することが割と運用上難しいところがあるのでは？と感じている点があるので何もわからない自分が書いているメモ書きと学びをあとからドキュメントに落とし込んでいければ「はじめまして！」の方にも優しいものができあがるかなと思います。

ドキュメントの必要性

この点は、OpenBSDの思想に基づいています。
OpenBSD - Wikipedia

目標としているのは「正しい思想」(correctness) と「先制的なセキュリティ」(proactive security) である。オープンソースおよびドキュメンテーションの重視、ソフトウェアライセンスに妥協しない姿勢でも知られている。テオ・デ・ラートの自宅がアルバータ州カルガリーということで、暗号の輸出制限がないカナダを開発の本拠地としている。ロゴおよびマスコットはフグのPuffy。

GoogleのSREとしてのドキュメント上でのUNIX哲学の思想からものは、UNIX子孫のBSD系の思想も間違いでは無いはずです。

そもそも理解出来る人間がいなければ継続的なセキュリティを担保することも難しいものがあります。

おわりに

あまり、実際に業務で触れている製品、サービス等に関してはセキュリティ面もあるのでここでは触れていませんがなんとかなる！という気持ちでいけばなんとかなるということです。
そのなんとかなっている部分がパイセンのおかげで成り立っているので、よりよいものにしていきたいなと思います。

一日づつわかることが増えれば、それだけ未来の自分を見据えることが出来るので地道に趣味でもなんでも一緒に頑張りましょう！

というわけで今日はここまで。
また、よろしくおねがいします。