One Week as an SRE After Being an Infrastructure Engineer
Hello, I'm incompetent.
I did some research myself, but I couldn't find many records from people working as SREs before starting the job, so I'm writing this down here because I couldn't form a clear image.
This first part is an intermission, covering aspects not directly related to work, so people from other professions can also enjoy it.
About Me
- Vintage shop owner for about 3 to 4 years
- Infrastructure engineer for 1 year
I've always liked computers, so I've been building homepages on rental servers since around 6th grade, repairing self-built PCs with soldering irons since junior high, and learning CGI books to set up bulletin boards on rental servers.
Although I graduated from a high school specializing in information technology, there weren't many job openings in what was then called the information and communication industry or IT in Sendai, so I wondered if I could really make a career out of it and just drifted along.
Now, for work, I've become a Tokyo resident starting this month.
I started working at the vintage shop after the owner at the time asked me if I wanted to work there, first as a part-timer, and then I became a full-time employee.
Introduction: The Week That Flew By
I moved to another prefecture and was working at a frantic pace until December 27th of last month, so I had to switch my mindset in various ways, and that took a lot out of me.
Given that I received this opportunity at 23, I was running at full speed.
I decided on a house without even viewing it, but it's a big plus that it's relatively close to work and has the following nearby:
- 100-yen shop
- Inexpensive Chinese restaurant
- Independent second-hand shop
When I arrived home, to my surprise, there was no ceiling light, so I lived without electricity for about 1-2 days after moving in, but it wasn't too difficult. Waking up when it's bright and sleeping when it's dark is an incredibly good way to reset your body clock.
Days of Unfamiliarity with macOS and Mac US Layout
As a current enthusiastic GNU/Linux and BSD user, this was a point of concern for me.
However, Macs with M1/2/3 chips, highly praised by Linus himself, are incredibly powerful.
It was my first time using .zsh itself, but since it's essentially a superset of bash, I didn't have much trouble. However, the default $PS1 prompt display was minimal and lacked color scheme settings, so I adjusted it to match my Artix Linux.
I guess I only set up the bare minimum for my .vimrc.
Mac US Layout!
With the compact MacBook's JIS layout, the keys themselves are extremely condensed, which made me uneasy. Also, the half-width/full-width key doesn't exist in the same place on a MacBook JIS layout, so I opted for the US layout, but it's still hard to get used to when you're accustomed to JIS.
This is a problem that can ultimately be resolved by using an external keyboard, so if it becomes unbearable later, it can be dealt with.
I said in a previous blog post that I should buy a ThinkPad keyboard...? That's an illusion...
Someone I saw writing articles on Qiita is here...
When someone who writes articles on Qiita is in the company, it feels like a one-sided offline meeting because I've been reading their articles unilaterally, but they don't know me.
It's interesting to learn about the background, like the origin of Qiita's name or the icon's origin.
Operational Flow, Business Flow, and Other Matters
This varies by organization, so I had to grasp the flows from chats and other sources, recognize them as various components, and combine them in my mind to form an image.
Just as the usage of the same software can change (e.g., Nginx can be used as a web server or function as a proxy server), forming an image of how everyone handles daily tasks in terms of business flow has been quite challenging, but thanks to a kind senior, I'm gradually understanding it.
Overwhelmed with gratitude to everyone.
Take Daily Notes Every Day
Since I'm a regular vim user, taking notes in Markdown format is convenient when writing daily reports later. Also, even trivial notes often become necessary later on, so regarding what to start writing, simply pasting URLs seen during meetings into your notes might be a good idea.
It's useless if internal security prevents viewing without authentication only from the terminal, but I'll promote a tool I created that retrieves titles from URLs and outputs them in Markdown format, as it was useful during work.
GitHub - haturatu/ght: go-http-title Get website title
Frankly, there's not much one can do initially, but the benefits of organization-wide IaC
Every day is a learning experience, making these days very enjoyable.
A major difference, especially from an infrastructure engineer, is the assumption of more cloud-like operations, which makes it harder to grasp the overall architecture, but of course, my original way of thinking is often useful.
While IaC implementation has its difficulties, being able to check the configuration in text form when it's managed as code, rather than having to view every piece of necessary information one by one only on a complete Web GUI, offers many advantages in terms of ease.
What are the disadvantages?
My impression is that there aren't many specific disadvantages, but it's hard to grasp the operational image at the very beginning. So, I want to contribute to the documentation to help future SRE team members who join later.
As stated in Google's SRE documentation, operating as a small, elite team is recommended, but I think this can increase the workload for team members. Therefore, I feel that achieving complete documentation is quite difficult operationally. So, if I can later incorporate my notes and learnings, written when I knew nothing, into the documentation, it might create something helpful for newcomers.
The Necessity of Documentation
This point is based on the philosophy of OpenBSD.
OpenBSD - Wikipedia
Its goals are "correctness" and "proactive security". It is also known for its emphasis on open source and documentation, and its uncompromising stance on software licenses. As Theo de Raadt's home is in Calgary, Alberta, Canada, which has no export restrictions on cryptography, it serves as the development base. Its logo and mascot are Puffy the pufferfish.
From the perspective of the UNIX philosophy in Google's SRE documentation, the philosophy of the BSD family, a descendant of UNIX, should also be correct.
In the first place, it's difficult to ensure continuous security if there are no people who can understand it.
Conclusion
I haven't touched upon the products and services I actually use in my work here due to security concerns, but the gist is that if you approach it with a 'we'll manage!' attitude, you will manage.
Since that 'managing' part is thanks to my seniors, I want to make things even better.
If we learn more each day, we can better envision our future selves, so let's steadily work hard together, whether it's for hobbies or anything else!
So, that's all for today.
Until next time!