From d93c77ca24d298666567f7b90e8b5ec7690eaaf7 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Wed, 12 Jan 2022 23:01:20 +0000 Subject: Publishing new version --- contact-information.html | 37 ++++++++++++-------- ...-12-26-how-to-stay-sane-as-a-devops-person.html | 37 +++++++++++--------- gemfeed/atom.xml | 39 ++++++++++++---------- gemfeed/index.html | 2 +- index.html | 4 +-- 5 files changed, 70 insertions(+), 49 deletions(-) diff --git a/contact-information.html b/contact-information.html index e34fc5fe..4050900c 100644 --- a/contact-information.html +++ b/contact-information.html @@ -8,31 +8,42 @@

Contact information

E-Mail

Personal information

Secure E-Mail: paul.buetow at protonmail dot com
E-Mail: paul at buetow dot org (forwards to the ProtonMail address)
Name: Paul Christopher Buetow
Born in: Germany
Home town: London, UK
E-Mail: paul at buetow dot org

Why did I mention 2 E-Mail addresses here? The buetow.org address will always stay. It is my lifetime E-Mail address as I own the domain name. The address will remain even when I decided to change my e-mail provider. Please note that I also mentioned snonux@snonux.de on some pages on this site. That's just an E-Mail alias for the above.

Use the ProtonMail address if you care about security for now. The address stays valid as long as I am ProtonMail user. Especially if you are ProtonMail user too, we could have real E-Mail end-2-end encryption for our conversation.

Currently, the E-Mail address forwards to paul dot buetow at protonmail dot com.

Quick Links

My sites

-gemini://snonux.de: My personal Gemini capsule
-gemini://buetow.org: Same as above
-https://snonux.de: My personal blog and internet site (same content as the Gemini capsule)
-https://buetow.org: Same as above

Social Media

I am sharing articles that I found interesting regularly on all the social media channels. To get you navigated quickly, here are the links:

I am sharing articles that I found interesting regularly these social media channels:

My LinkedIn profile
My Twitter profile
My Telegram channel

Internet Relay Chat

I am on irc.german-elite.net in #talk, #coding, #linux (and maybe in others) as rantanplan.

I am on irc.german-elite.net in #talk, #coding, #linux (and maybe in others) as "rantanplan".

My Open Source code repositories

My personal Codeberg page
My personal GitHub page (slowly moving all my stuff over to Codeberg)
DTail at Mimecast
-I/O Riot at Mimecast
+I/O Riot at Mimecast (currently, not maintained)
+

My Gemini capsule

+gemini://snonux.de - My internet site and blog
+gemini://buetow.org - Alias for above
+

Wondering what's the Gemini protocol about? Read:

+Welcome to the Geminispace
+

The addresses above are hosted in Germany. Alternatively, you can add a "www" for using a mirror in Japan:

+gemini://www.snonux.de
+gemini://www.buetow.org
+

My website

The content is the same as the Gemini capsule, but reachable via HTTP+HTML:

+https://snonux.de - My internet website and blog
+https://buetow.org - Alias for above
+

The addresses above are hosted in Germany. Alternatively, you can add a "www" for a mirror in Japan:

+https://www.snonux.de
+https://www.buetow.org

That's all for now...

Go back to the main site

Generated with Gemtexter, served by OpenBSD/httpd(8)

diff --git a/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html b/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html index 9e3bcec4..4cf3bf8d 100644 --- a/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html +++ b/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html @@ -29,22 +29,23 @@ -----||-/------`-._/||-o--o---o--- ~~~~~' -

Published by Paul Buetow 2021-12-26, last updated 2021-12-31

Published by Paul Buetow 2021-12-26, last updated 2022-01-12

Log4shell (CVE-2021-44228) made it clear, once again, that working in information technology is not an easy job (especially when you are a DevOps person). I thought it would be interesting to summarize a few techniques to help you to relax.

(PS: When I mean DevOps, I also mean Site Reliability Engineers and Sysadmins. I believe SRE, DevOps Engineer and Sysadmin are just synonym titles for the same job).

https://en.wikipedia.org/wiki/Log4Shell

Set clear expectations

It's important to set clear expectations. It can be difficult to guess what others expect or don't expect from you. If you know exactly what you are supposed to do, you can work towards a specific goal and don't worry about all the other noise so much.

However, if you are in a more senior position, it is expected from you to plan your tasks by yourself to a large degree and also be flexible, so you can react quickly to new situations (e.g. resolving incidents). Also, to a large degree, you have to prioritise your work by yourself. This can overthrow all of your plans. In this case, it sometimes helps to share your plans with your team in order to be sure that everyone is on the same page. Afterwards, be the execution machine. People are happy when they see that stuff gets done. Communicate clearly all critical work you do. This will capture all the technical debt there might be. It does not help you in the long run if you are fixing everything in the background and nobody noticing it.

Due to politeness, many people are afraid to set clear expectations. I personally may sound sometimes "too German" when setting expectations, but so far nobody complained, and I have only received positive feedback so far.

However, if you are in a more senior position, it is expected from you to plan your tasks by yourself to a large degree and also be flexible, so you can react quickly to new situations (e.g. resolving incidents). Also, to a large degree, you have to prioritise your work by yourself. This can overthrow all of your plans. In extreme cases, it can help to share your plans with your team so that everyone is on the same page. Afterwards, be the execution machine. People are happy when they see that stuff gets done. Communicate clearly all critical work you do. This will capture all the technical debt there might be. It does not help in the long run if things are fixed in the background without any visibility.

Due to politeness, many people are not setting clear expectations. I personally may sound sometimes "too German" when setting expectations, but so far nobody complained, and I have even received positive feedback about it.

Always respond to requests but set expectations and boundaries

There are many temptations to get side-tracked by other projects and/or issues. It is important to set boundaries here. But always answer to all requests as nothing is more frustrating than asking a person and never getting any answer back. This is especially frustrating when everyone is working form home and people are using tools such as Slack and E-Mail for most of their communications.

What about saying "no"...

If the request is urgent, and you have the capacity, probably you should work on the request. If it's not urgent, maybe ask to pospone the request (e.g. ask the other person to create a ticket). If it is urgent, but you don't have the knowledge or the capacity to help, try to defer the request to a colleague who might be able to help. You could also provide some quick tips and hints, so that the requester can resolve the issue by himself. Make it transparent to the requester why you might not have the time right now, as this can help the person to review his own priorities or to escalate.

There are many temptations to get side-tracked by other projects and/or issues. It is important to set boundaries here. But always answer to all requests as nothing is more frustrating than asking a person and never getting any answer back. This is especially the case when everyone is working form home where people are using tools such as Slack and E-Mail for most of their communications.

Dealing with requests

If the request is urgent, and you have the capacity to help, probably you should help. If it's not urgent, maybe ask to pospone the request (e.g. ask to create a ticket, so that someone from your team can work on it later).

If the request is urgent, but you don't have the knowledge or the capacity to help, try to defer to a colleague who might be able to help. You could also provide some quick tips and hints, so that the requester can resolve the issue by himself. Make it transparent why you might not have the time right now, as this can help the person to review his own priorities or to escalate.

Escalation is only a tool

Never make or take an escalation personally. The only forms of escalation should be due to technical issues or lack of resources. An escalation then becomes like a math equation and does not need human resources involved. So de-facto, an escalation is nothing negative, but just a process people can follow to form decision-making. In a good company escalations should to be an exception though, as workers know how to deal with the things by themselves without bothering management too much.

Never make or take an escalation personally. The only forms of escalation should be due to technical issues or lack of resources. An escalation then becomes like a math equation and does not need human resources involved. So de-facto, an escalation is nothing negative, but just a process people can follow to form decision-making. In a good company escalations tend to be an exception, though. Staff knows how to deal with the things by themselves without bothering management too much.

Think positively

If times are very stressful, think that it could be worse:

If times are very stressful, think that it could always be worse:

Nobody is dying, we are only doing some IT stuff.
Your time after work is your own time, look forward to time with your family or a nice dinner or your favourite sports class.

Go slower even if you could go faster

When working in a team, you may feel that you could get done things faster when you just did everything by yourself. This can be a bit frustrating at times, as you might need to work late hours and also might need to explain things over and over again to others. Also, you could be the one who needs to get things explained over and over again as you are not so familiar with the topic (yet). You will appreciate it if the other person is slowing down for you a bit.

You work in a team

Security is a team sport. So slow down and make sure that everyone is on track with the goals. You can go full-speed with your very own subtasks, though. Not everyone knows how to use all the tools so well like a full-time DevOps person. As a DevOps person, you are not a security expert, though. Security experts are different people in your company, but DevOps will be the main tribe deploying mitigations (following the security recommendations) and management will be the main tribe coordinating all the efforts. So even if you think that you can do everything faster by your own, can you really?

So even if you think that you can do everything faster by your own, can you really? You probably don't know what you don't know about IT security. The more you know about it, the more you know about what you don't know.

Don't rush

Slowing down also helps to prevent errors. Don't rush it, even if the task you are working on is urgent. Try to be quick, but don't rush it. Maybe you are writing a script to mitigate a production issue. You could others peer review that script, for example. Their primary programming language may not be the same (e.g. Golang vs Perl), but they would understand the logic. Or ask another DevOps person from your company with good scripting skills review your mitigation, but he then may lack the domain knowledge of the software you are patching. So in either case, the review will take a bit longer as the reviewer might not be an expert in everything.

So relax, don't always expect immediate results. Set clear and reasonable timelines for the management about the mitigations. You are not a superhero who has to do everything by yourself. Sometimes, you will miss a deadline. But that will have a good reason. Don't rush to complete just to meet a deadline.

Slowing down also helps to prevent errors. Don't rush your tasks, even if they are urgent. Try to be quick, but don't rush them. Maybe you are writing a script to mitigate a production issue. You could others peer review that script, for example. Their primary programming language may not be the same (e.g. Golang vs Perl), but they would understand the logic. Or ask another DevOps person from your company with good scripting skills review your mitigation, but he then may lack the domain knowledge of the software you are patching. So in either case, the review will take a bit longer as the reviewer might not be an expert in everything.

So relax, don't always expect immediate results. Set clear and reasonable timelines for the management about the mitigations. You are not a superhero who has to do everything by yourself. Sometimes, you will miss a deadline. But that will have good reasons. Don't rush to complete just to meet a deadline.

You are not a superhero

Always keep that in mind. You can't solve all problems by your own. Maybe you could, but that would be a lot of additional pressure and stress (and this will reflect to your personal life). Also, Superman and Wonder Woman receive much higher salaries than you will ever do ;-).

I have been a superhero multiple times mitigating critical incidents, and I was proud about it. But actually, I should not have been proud of it, as for everything there should be other people around who should be able to resolve an incident. No company should rely on a single person, there must always be a substitute. You are not a superhero and as harsh as it sounds, everyone is replaceable. Every superhero can be replaced with another superhero. The only thing it takes to become a superhero is time to get to know the infrastructure and tools very well, paired with work dedication.

Always keep that in mind. You can't solve all problems by your own. Maybe you could, but that would be a lot of additional stress (and this will reflect to your personal life). Also, Superman and Wonder Woman receive much higher salaries than you will ever do ;-).

I have been a superhero multiple times mitigating critical incidents, and I was proud about it in those moments. But actually, I am not proud looking at those retrospectively as for everything there should be other people around who should be able to resolve an incident. No company should rely on a single person, there must always be a substitute. You are not a superhero and as harsh as it sounds, everyone is replaceable. Every superhero can be replaced with another superhero. The only thing it takes to become a superhero is time to get to know the infrastructure and tools very well, paired with work dedication.

This doesn't mean, that you shouldn't try your best. But you don't need to try to be the superhero. Maybe someone else will be the superhero, but that's OK as long as it's not always the same person every time. Everyone can have a good day after all. If I could choose between being a superhero or having a good night sleep, I would probably prefer the sleep.

Give away some of your superpowers

If you are a superhero, try to give away some of your superpowers, so that you can relax in the evening knowing that others (e.g. the current on-call engineers) know how to tackle things. Every member of the team needs to do DevOps (even the team managers, in my humble opinion). Some may be less experienced than others or have other expertises, but to counteract this you could document the recurring tasks so that they are easy to follow (which then later could be either automated away or, even better, fully fixed).

On the other side, if you are a DevOps person, try to sneak into other people's shoes too. For example, you might not be an expert in Java programming, but a lot of the infrastructure is programmed in Java. This is where usually the Software Developers and Engineers shine. But if you know how to read, debug and even extend Java code too (by learning from the Software Developer superheroes), then your will only benefit from it.

So you are not a superhero. Or, if you are a superhero, then all colleagues should be superheroes too.

Don't jump on all problems immediately

In order to distribute the troubleshooting skills across the team, you should not jump on every problem immediately. Leave some space for others to resolve the issue. This is where the best learning happens. Nobody will learn from you when you solve all problems. People might learn something after you explained what you did, but the takeaways will be minimal compared to when people try to resolve issues by themselves. Always be available for questions which will help your colleagues to steer into the right direction and if you think it helps, give them some tips resolving the issue, even if they didn't ask for it. Sometimes, engineers are too proud to ask.

There is an exception, though: If the issue is a very critical one, then you might better off trying to resolve it as fast as possible with your full powers in order to avoid any major damage to the company. Best, in a team-effort, though. Unfortunately, solving it with the team is not always the fastest way. So in this particular circumstance, the company may be better off being saved by a single superhero. Make sure that the problem will not occur again or, at least, that others can fix it the next time without Superman flying by.

In a perfect world, every member of a team comes along with the same strengths and skills. But in reality, everyone is different.

The whole paragraph changes when there is an issue you don't know how to resolve. Jump on it, so you can learn from it. But also ask for advice if you are unsure about it.

If the issue is a very critical one, then you might better off trying to resolve it as fast as possible with your full powers in order to avoid any major damage to the company. This, of course, only works if you know how to resolve it quickly. So, don't leave others with not much experience yet looking at it. If possible, work with the team to resolve the issue. Unfortunately, solving it with the team is not always the fastest way. So in this particular circumstance, the company may be better off being saved by a single superhero. Make sure that the problem will not occur again or, at least, that others can fix it the next time without Superman flying by.

Force breaks; and shutdown now

Be strict about your time off. Nowadays, tech workers check their messages also out of office hours and are reachable 24/7. This really should only be the case when you are on-call, to be honest (or if you work for a startup). All other out-of-office time is owned by you and not your employer. You have signed an 40 hour/week and not 7 days/week contract. Of course, there will be always some sort of flexibility and exceptions to the rule. You might need to work over the weekend to get a migration done or a problem solved. But to balance it out, you should have other days off as substitutes.

Be strict about your time off. Nowadays, tech workers check their messages also out of office hours and are reachable 24/7. This really should only be the case when you are on-call, to be honest (or if you work for a startup). All other out-of-office time is owned by you and not your employer. You have signed an 40 hour/week and not 7 days/week contract. Of course, there will be always some sort of flexibility and exceptions. You might need to work over the weekend to get a migration done or a problem solved. But to balance it out, you should have other days off as substitutes.

It's important to shut down your brain from work during your breaks (be strict with your breaks, leave your desk for lunch or for a walk early afternoon and if you aren't on-call also don't take your work-phone with you). You will be happier and also much more energized and productive in the afternoon. Also, when you are reachable 24/7, your colleagues will start thinking that you don't have anything more important to do than work.

Block time every day for personal advance

It does not matter how many tasks are in your backlog or how many issues are to be tackled. *Always* find time for personal advance. The most issues aren't critical anyway and can wait a bit. At the end of the day, you will have a nice feeling that you have accomplished something meaningful. This can be an interesting project or learning a new technology you are interested in. Of course, there must be consensus with your manager (unless you do that kind of thing in your personal time of course).

- 2022-01-06T08:30:53+00:00 + 2022-01-12T05:34:41+00:00 snonux.de feed Having fun with computers! @@ -452,22 +452,23 @@ PAUL:X:1000:1000:PAUL BUETOW:/HOME/PAUL:/BIN/BASH -----||-/------`-._/||-o--o---o--- ~~~~~' -

Published by Paul Buetow 2021-12-26, last updated 2021-12-31

Published by Paul Buetow 2021-12-26, last updated 2022-01-12

(PS: When I mean DevOps, I also mean Site Reliability Engineers and Sysadmins. I believe SRE, DevOps Engineer and Sysadmin are just synonym titles for the same job).

https://en.wikipedia.org/wiki/Log4Shell

Set clear expectations

However, if you are in a more senior position, it is expected from you to plan your tasks by yourself to a large degree and also be flexible, so you can react quickly to new situations (e.g. resolving incidents). Also, to a large degree, you have to prioritise your work by yourself. This can overthrow all of your plans. In extreme cases, it can help to share your plans with your team so that everyone is on the same page. Afterwards, be the execution machine. People are happy when they see that stuff gets done. Communicate clearly all critical work you do. This will capture all the technical debt there might be. It does not help in the long run if things are fixed in the background without any visibility.

Always respond to requests but set expectations and boundaries

What about saying "no"...

There are many temptations to get side-tracked by other projects and/or issues. It is important to set boundaries here. But always answer to all requests as nothing is more frustrating than asking a person and never getting any answer back. This is especially the case when everyone is working form home where people are using tools such as Slack and E-Mail for most of their communications.

Dealing with requests

Escalation is only a tool

Never make or take an escalation personally. The only forms of escalation should be due to technical issues or lack of resources. An escalation then becomes like a math equation and does not need human resources involved. So de-facto, an escalation is nothing negative, but just a process people can follow to form decision-making. In a good company escalations tend to be an exception, though. Staff knows how to deal with the things by themselves without bothering management too much.

Think positively

If times are very stressful, think that it could be worse:

If times are very stressful, think that it could always be worse:

Nobody is dying, we are only doing some IT stuff.
Your time after work is your own time, look forward to time with your family or a nice dinner or your favourite sports class.

Go slower even if you could go faster

You work in a team

Don't rush

So relax, don't always expect immediate results. Set clear and reasonable timelines for the management about the mitigations. You are not a superhero who has to do everything by yourself. Sometimes, you will miss a deadline. But that will have good reasons. Don't rush to complete just to meet a deadline.

You are not a superhero

Give away some of your superpowers

So you are not a superhero. Or, if you are a superhero, then all colleagues should be superheroes too.

Don't jump on all problems immediately

In a perfect world, every member of a team comes along with the same strengths and skills. But in reality, everyone is different.

The whole paragraph changes when there is an issue you don't know how to resolve. Jump on it, so you can learn from it. But also ask for advice if you are unsure about it.

Force breaks; and shutdown now

Be strict about your time off. Nowadays, tech workers check their messages also out of office hours and are reachable 24/7. This really should only be the case when you are on-call, to be honest (or if you work for a startup). All other out-of-office time is owned by you and not your employer. You have signed an 40 hour/week and not 7 days/week contract. Of course, there will be always some sort of flexibility and exceptions. You might need to work over the weekend to get a migration done or a problem solved. But to balance it out, you should have other days off as substitutes.

Block time every day for personal advance

snonux.de's Gemfeed

Having fun with computers!

2022-01-01 (1134 words) - Bash Golf Part 2

2021-12-26 (2101 words) - How to stay sane as a DevOps person

2021-12-26 (2275 words) - How to stay sane as a DevOps person

2021-11-29 (1281 words) - Bash Golf Part 1

2021-10-22 (2276 words) - Defensive DevOps

2021-09-12 (1365 words) - Keep it simple and stupid

echo 'Hello $USER'

Having fun with computers!

echo "Hello $USER"

               ,---------------------------,
               |  /---------------------\  |
-- 
cgit v1.2.3