Life's more painless, for the brainless
~$whoami
Name: Willem | Nationality: Dutch | |
Nickname: Kamaradski | Residence: Germany |
TL;DR:
Years of experience:
- 17 years of technical hands-on
- 14 years of people management (my team principles)
- 13 years in outsourcing business
- 10 years experience in financial services
personal Keywords:
Ideas
; concept creator
; free-thinker
; hard-working
; dedicated
; sharing
; creative
; fun
; precise
; family
; do-er
; together
; do right
; learning
; persistent
; outgoing
; music
; cars
; hands-on
; mechanics
; garden
; autodidactic
; metal detecting
; reading
; gaming
;
Skill Keywords:
Operating systems: | mac ; windows ; linux ; ubuntu ; xubuntu ; debian ; slackware ; Server2003 ; Server2008 |
Virtualization/servers: | proxmox ; docker ; docker swarm/compose ; lxc ; ecs ; virtualbox ; nginx ; apache ; Postfix ; dovecot ; sieve |
Networking/infrastructure: | pfsense ; opnsense ; different hardware ; SES ; VPC ; subnetting ; VLAN ; VPN (openVPN, WireGuard) |
Programming: | python ; bash ; powershell ; basic ; assembler ; php ; html ; lua ; lsl |
CMS/ticketing/etc..: | trac ; phabricator ; xwiki ; wiki.js ; jira ; confluence ; sphinx ; git ; gitlab ; ms office ; open/libre office ; google docs ; google big query ; OTRS ; Xerox DocuShare ; Sharepoint |
Monitoring: | elasticsearch ; prometheus ; loki ; grafana ; influxDB ; ci/cd ; check_mk ; nagios ; icinga ; munin |
Business: | techops ; finops ; devops ; process documentation ; process management ; process visualization ; six-sigma ; lean ; advanced troubleshooting ; KPI/SLA/SLI management |
Hardware: | basic component level electronic repair |
Work Experience:
Feb-2022 --> Ongoing: Xolvis GmbH, Germany
- Job title: Director of Technical Operations
- LOB: SaaS and Payments solutions in the automotive industry
- Responsibilities:
Responsible for the complete technical operations with exception of the Development department: DevOps, TechOps, IT Service desk and also Business Operations. As part of a fast growing start-up these departments all needed to be redesigned and concepted from the ground up to support hyper scalability in the near near future. This is not only true for the organizational structures of these departments, but also for the actual technology and tools in use from our cloud infrastructure all the way to the tools we use to deliver our customer support.
Oct-2013 --> Jan-2022: PPRO Financial Ltd, Germany
- Job title: Head of (Technical) Operations
- LOB: Digital Financial Services, Payment Service Provider
- Responsibilities:
Responsible for the technical operations inside PPRO. SLA/KPI tracking of the local team in Germany, as well as the outsourced partner team in other locations. Responsible for the software development of our internal tools. Responsible for the infrastructure used to host the operational toolings that we develop in-house. Operating the monitoring tools used by operations, and responsible for the monitoring design of how we live monitor and alert for our business performance metrics and events. Ultimate responsibility for the on-call service and incident management. Change management for migrations and new products as well as updates to software and infrastructure. Technical partner management for our payment scheme partners. 3rd level support team. Responsible for all FinOps before we split this off into a separate team. Also responsible for the Viabuy/Crosscard pre-paid credit card technical operations before it was sold on. The last 6 months of my employment at PPRO i have also been leading the "tooling & monitoring” engineering team as principal engineer.
Aug-2012 --> Sep-2013: ProSiebenSat.1 Media AG, Germany
- Job title: Digital Content Manager for Maxdome.de
- LOB: Digital content delivery B2C
- Responsibilities:
Responsible for bringing and keeping digital content online in the online streaming service. Transcoding and encryption from master-video to Microsoft Smooth Streaming System with DRM. Uploading and management of content on the content servers via SFTP. Troubleshooting of the TM and CPS Managers as well as managing the FSK-ratings and metadata info online and in the internal CMS-system.
Jul-2011 --> Mar-2012: William Hill Online Casino, Bulgaria
- Job title: VIP Manager
- LOB: Global Service Desk, B2C
- Responsibilities:
Identify existing and upcoming big customers through game-play and spending pattern analysis. Account management for all VIP customers in the Dutch\Belgium market.
Oct-2009 --> Oct-2011: Sutherland Global Services EOOD, Bulgaria
- Job title: Team Manager / Team Manager Collections
- LOB: Technical support and customer care, B2C / Finance and Accounting Outsourcing, B2C
- Responsibilities:
People management, in charge of setting up the technical and organizational structure for the start-up of the projects, including transition and implementation. Primary POC for the client, overseeing the recruitment process. Monitoring KPI’s and SLA’s, documenting the project structure, developing and implementing processes, handling escalations, developing and executing the quality management system, conduct training and create the training materials, driving innovations, maintain consistent data entry into the CRM database, WFM scheduling, developing reports for internal and external, business outlook and forecast. Projects where I was leading teams for include: Jamba, McAffee, Dell.
Oct-2007 --> Oct-2009: IBM, Scotland
- Job title: Global Technical Mentor Lead
- LOB: Technical Support Centre. B2B & B2C Customers
- Responsibilities:
Negotiate contractual KPI’s with the client, analyzing KRI & KPI results to identify improvement opportunities, Create and conduct train-the-trainer & train-the-student sessions, Developing training materials for both student and mentors, Responsible for technical troubleshooting QA, Creating and updating the digital knowledgebase, Sole responsible for the resource DocuShare site, Responsible for maintaining the test-lab in all 3 geo-locations.
2007 --> 2007: KPN Contact B.V. the Netherlands
- Job title: CSR 2nd line and Crisis control team agent
- LOB: Technical Support Centre ISP. B2C Customers
- Responsibilities:
VOIP service support. Both 2nd line FLO and part of the crisis team dealing with solving the nationwide product implementation issues, developing and implementing new service solutions.
2005 --> 2007: Borkes Computers and Office Centre, the Netherlands
- Job title: Technical service and solution engineer
- LOB: Computer solutions and store. B2B & B2C Customers
- Responsibilities:
Head of the outdoor department, administrative coordination, Architect, implement and maintain complete network and server solutions to SMB customers. covering both the hardware and software aspects. Building computers based on customer needs, repairing and installing computers, and peripheral equipment on location.
2003 --> 2005: Combatel B.V., the Netherlands
- Job title: General Branch Manager
- LOB: Computer store. B2B & B2C Customers
- Responsibilities:
Overall responsibility for the branch, leading the technical department for hardware and software repair, stock management, advertisement strategy, sales and purchase, recruitment and hiring, people management.
Awards & Recognitions:
- IBM Employee of the month April 2008
Language skills:
Read | Write | Spoken | |
---|---|---|---|
Dutch | Native | Native | Native |
English | Fluent | Fluent | Fluent |
German | Fluent | Proficient | Fluent |
Bulgarian | Insufficient | Insufficient | Conversational |
Courses:
Internal Sutherland Global Services Training:
- LEAD initiative
- Six Sigma – Yellow belt
- Execution excellence – Bronze belt
Internal IBM – Xerox – Education:
- Xerox technical mentor training
- Advanced networking
- Subnetting
- Supernetting
- Introduction to Macintosh
- Working on a commercial account
- Call monitoring Feedback
- Coaching
- Performance Management
- Root Cause Analysis
- Action Planning
- Windows NT 4.0 – Aan de slag (Basic NT 4.0)
- Introducing Windows XP
- Installing Windows XP
- Windows XP – Fundamentals
- Backup and Security Settings in Microsoft XP
- Up and Running with Microsoft Windows
Internal KPN education:
- KPN VOIP & advanced Telephony training
- KPN call centre VOIP technical training
- KPN call centre communication training
Education:
When | What | Where |
---|---|---|
2000 | Asbestos safety training | Hoogeveen, Netherlands |
2000 | Basic safety on the work floor VCA-1 | Hoogeveen, Netherlands |
1996 | ARBOUW safety course | Assen, Netherlands |
1996 - 1998 | ROC Construction vocational college | Ruinen, Netherlands |
1992 - 1996 | LTS Construction techniques | Assen, Netherlands |
~$Extracurricular
A person is shaped by everything one does.
Reading Study List:
Networking
- Oskar Andreasson – Iptables Tutorial 1.1.19 (2003) (read here)
- Charles M. Kozierok – The TCP/IP Guide (2005) (read here)
- Ralph Becker – IP Address Subnetting Tutorial (2007) (read here)
- Manuel Kasper & Chris Buechler – M0n0wall Handbook (2008) (read here)
Cloud Architect/Engineer & IaC
- Yevgeniy Brikman - Terraform: Up & Running - Writing infrastructure as code (Second Edition) (2019) - O’Reilly
- Gojko Adzic - Specification by Example - How successful teams deliver the right software (2011) - O’Reilly
- Irakli Nadareishvili, Ronnie Mitra, Matt McLarty & Mike Amundsen - Microservice Architecture - Aligning principles, practices, and culture (2016) - O’Reilly
Developer
- Mark Summerfield - Programming in Python 3 - A complete introduction to the Python Language (2010)
- Michael Dawson - Python Programming for the Absolute Beginner (Third edition) (2010)
- Caleb Doxsey - Introducing Go - Build reliable, scalable programs (2016) - O’Reilly
Classic System Administration
- Duane Wessels - Web Caching (2001) - O’Reilly
- International Technology Solutions Inc – Windows Integration with Samba (2001)
- Jay Ts - Robert Eckstein - David Collier-Brown - Using Samba (Second edition) (2003) - O’Reilly
- Christopher Hertel – Implementing CIFS – The Common Internet FileSystem (2003) - O’Reilly
- Duane Wessels - Squid The Definitive Guide (2004) - O’Reilly
- Christopher Smith – Linux NFS-HOWTO, Revision 4.0 (2006) (read here)
Operating Systems
- Slackware Linux Essentials (The Slackbook) (English)
- FreeNAS™ 8.0.1 Users Guide
Marketing and Business
- Seth Godin – Purple Cow (English)
- Seth Godin – The Big MOO (English)
Other
- Kate Fox – Watching the English (Anthropology)(English)
- El James – Shades of Grey (Band-I & II & III) (German)
- Jean M. Auel – The Clan of the Cave Bear (Band-I & II & III & IV & V & VI) (Dutch)
Online community management
Ahoyworld.co.uk
For ahoyworld.co.uk (red. now ahoyworld.net) I used to have a leading role as a core-staff member. Ahoyworld is an active gaming community with 1000+ members, that is participating in online computer gaming on different platforms. For Ahoyworld I have fulfilleded the following tasks:
- Core-staff member (similar to a c-level)
- Server administration and maintenance
- Project management & administration tool implementation
- Gameserver automation development (mostly in PowerShell)
- Game add-on developer (Arma 3 LUA)
Completed self-study projects
Note: Though some projects mentioned on this page are still in an active state, and running today in some an evolved shape of form, this part of the page is mostly historical.
Jira Ticketing system
Target: Design and set up a Jira workflow for an online community with 1000+ members.
Implemented solution: Created different employee & member groups and several projects, all different access levels and cross memberships for internal employees as well as external users. Some of the projects included:
- Coding projects, with Bitbucket code, commit tracking, bug tracking, and project management.
- Different Ban-list trackers, with custom workflows
- Different project management projects
Squid cashing Proxy
Target: Design and build a small Squid cashing & proxy for use in a home network with 5 to 10 connected devices.
Implemented solution: Recycled an unused Pentium 4 3GHz machine with 1GB DDR-RAM system memory, 1x 10GB Seagate hard-drive for OS, 1x 250GB WD hard-drive for caching, 1x 3Com 1000Mbit NIC on-board on Asus mainboard for internal LAN connection, and 1x 100Mbit 3Com Pro PCI NIC for external WAN connection. Choice of operating system a totally stripped Slackware 10.x installation that claimed only 150MB drive-space, and Squid proxy software on top.
project status: Success, device served for about 1.5 years non-stop without problems, accelerating our frequently visited sites, and syncing the cache overnight. The device was also used for content filtering for minors. Came https, this project became less useful and I personally think HTTP cache/proxy is no longer useful. This problem is now best solved at the content server end.
FreeBSD Router
Target: Design and build a Router\\firewall use in a home network with 5 to 10 connected devices.
Implemented solution: The hardware of choice was an AMD-K6 400Mhz IBM computer at the time, adapted to be cooled fan-less, installed FreeBSD based M0n0Wall on a 64MB MMC flash-card plugged in on an IDE-2-MMC adapter making a real hard-drive redundant, the system was overloaded with the huge total of 128MB SD-ram system memory where only 32 MB was actually utilized at peak performance. Connectivity: 3x 100mbit 3Com PCI NIC\’s and a boosted (Deep Dish Cylindrical Parabolic Template) Linksys WLAN PCI Card System. The WLAN card provided high-range access point usability (separate VLAN). 1x 3Com NIC was used for WAN connection, 1x 3Com NIC was dedicated for the server and 1x 3Com NIC was used to hard-wire all remaining PCs and devices into the network. Certain traffic was bridged from the WLAN to reach the server (like SAMBA and NFS) while otherwise keeping the WLAN completely separated from my internal network.
project status: Great success, I kept this setup running for about 5 or 6 years without a single hick-up. The same set-up was replicated in several office environments where it was stretched to 100+ computers and several high-load servers without any issue. Eventually, I moved out of the country and had to leave it behind, and actually, I’m thinking to rebuild a similar setup as soon as I have some spare money and (mostly) time. This served me better than ANY commercial product I ever tried!
2021 update: Though massively evolved, this project is still ongoing. Evolving from using m0n0wall → self-managed FreeBSD with PF → PFsense → OpnSense, and from 1 machine on bare metal, I today have 2 instances of Opnsense running in Proxmox VM machines. One at home and one in the data center linked with dedicated site2site Wireguard VPN, and many different VLANs and subnets.
Samba-NFS-FTP
Target: Design and build a file-server capable to serve and stream content in a home network with 5 to 10 connected devices and providing external access to +/- 1000+ users in different access groups for an online gaming community.
Implemented solution: Asus p4p800E-deluxe mainboard, Pentium 4 3.2 GHz CPU, 2GB Kingston HyperX DDR memory, 1x 3Com 1000Mbit Pro NIC, Cased in a CoolerMaster tower fed with 450Watt PSU and loaded with 8x 250GB WD 7200rpm hard-drives providing a total stunning (at that time) 2TB drive-space! Installed DSL-Linux, Samba-server for my windows based devices, and NFS protocol for High-performance transfer rates for my Linux-based devices. Pure-ftpd was installed with SQL support for quick external access for myself and approximately 25 other admin-users, as well as roughly 1000 community members which regularly synced their installed gaming-mods against this repo.
project status: Success, Setup remained active for at least 3 years. A few times I replicated this in office environments, but then based on the more secure Ubuntu LTS server distributions. The only downside is that I found no support for Bandwidth quota’s, this should be done via a proxy server like Squid, Some FTP server software is available for the Windows OS are quicker and easier to install and administrate, so if I would have to build an FTP-only server I might not have chosen the Linux OS.
2020 update: This project actually continued its life for a long time, dunning on my data center server in different ways. It's been bare metal, it has been in jails, and also in Docker-swarm behind traefik. It is now however discontinues since early 2020.
~$team principles
Setting the right team culture inside the teams that I manage is key!
The following “rules” (or principles as I like to call them) are a set of ideas and mindsets that I have developed during my career as a people manager. I always have these ideas rotating in the office, and I from time to time quote them during my feedback sessions with my direct reports. The actual titles of these “rules” are more important than the text I have attached to them, let your employees give their own content to these “rules”, and discuss these ideas amongst the team in order for the team to naturally grow this to be their own DNA.
(click below rules to open & read)
Rule 01: "Assume nothing, Question Everything!"
Things are changing, fast! So whatever might have made sense in the past, might no longer do so today. Always look at something and ask yourself: can we do better & does this (still) make sense. Also people change, when you or someone else have implemented something in the past, you might now have new skills or ideas and you might be able to do a better job today. The same goes for people that have worked here in the past: the next person to join our team might have a better idea/plan. And of course, technology also doesn’t sit still. We might have better tools today, or the same technology might offer different possibilities.
Rule 02: "Never be unreachable."
Communication is key. If we all sit on our own personal island and are unreachable, we will never be able to reach great goals. This, of course, means not only reading your emails and chat but most importantly also means to keep for example one ear outside of your headset most of the time. A quick 1 sentence communication might make the difference between something happening, or getting forgotten and never done. pro-tip: just listening to what is happening or what is being said around you already makes a great difference in your generic awareness of things that are going on.
Rule 03: "Make it so!"
Do not just sit there and talk about it: make it happen. While endless meetings and discussions might provide you upfront insight into how things might turn out, however, nothing will actually happen until you make it so. The balance is important: planning/discussion and actually doing. It will be different from topic to topic: Larger more complex things might need more planning and discussion, however also here, maybe just to start doing it will give you valuable insight into reality. And especially smaller things like many small tasks related to emails, just do it and get it over with, you will be surprised how many small things you can get done this way. Same with ideas one can sit on the same idea for years pondering if it will work or not, or one can just make it happen and find it for real…
Rule 04: "Think, then do, then think again"
Never do anything without thinking first. However, you should also look back at what you have done and think if it renders the result you were aiming for. Looking at something in hindsight sometimes gives you even better ideas. Don't make this rule hinder you with rule-#3, but make it a smooth process of thinking&doing.
Rule 05: "Sometimes you're wrong.”
However good the idea or intention, sometimes you just are wrong. Not due to a failure in who you are or the way you think, but maybe plainly because you don't have all the information. Even worse: sometimes you might be right and still be wrong, just because someone else has a different goal in mind than what might be obvious.
Rule 06: "You don't waste good."
Something that is already there: might just need some small improvements, can be reused or upcycled in order to save effort/resources, might be used somewhere else, or even be reworked or repurposed. This is not only true for food, or physical items but especially for ideas, thoughts, plans, documentation, IP, etc..
Rule 07: "Always work as a team."
4-eyes see more than 2, 4 hands are able to move more work than 2, etc... however, do not be fooled that 4 hands are always faster or more efficient, and an extra pair of hands might actually also be counterproductive at times. In order to (make the dream work,) you need teamwork. (cheesy, yes I know, but it's actually true)
The general rule of thumb is to work together, not against each other. It’s also not a race: when a team works at the same constant pace, it’s faster than if all individuals try to race each other. Try to know your teammates, and to support them where you are stronger/better/more experienced than them in order to all move forward at the same speed.
Rule 08: "Never take anything for granted."
What is here today, might not be there anymore tomorrow. Try not to make yourself or your workflows depending on something specific (like a specific software tool, or 1 particular person). Always implement things in such a way that they can be migrated without breaking the process too much (or for too long). Also, learn from what is available today, so you can work independently in case it is not there anymore. Knowledge and understanding can always be applied to another tool/system/person, etc.. Thus this way you are always flexible to follow processes even if something in between is broken or missing. Kinda like MacGyver.
Rule 09: "Explicit is better than implicit."
Do not make me (or anyone else) guess what you want to say or do, be explicit about it. This will save you time immediately by reducing the need for explaining and discussing. And other people (as well as the future you) will love you for it when they look back at your work/code/documentation/project plan/Filesystem layout/etc…
Rule 10: "Don't believe what you're told. Double-check."
I’m not telling you that your colleagues are lying to you, not at all. However one person hardly ever has the full picture. Do your own research before coming to conclusions or proceeding to the next step. You will be surprised by what you will find along the way.
Rule 11: "The Devil is in the details"
Be precise and exact. Rule-#4 should also help you with this. after you have done something, review it. Meaning: run your code and observe if it works (try also to break it with unexpected data or situations), reread your documentation, double-check all configs, etc… Examples where this went wrong:
- A simple copy/paste error could mean we are sending the wrong amound of funds to the wrong customer
- A small logic error in the code could duplicate all outgoing transactions for a specific day
- Forgetting to change the currency from EUR to PLN might mean you are sending 4x more money to a customer than you intended to
Rule 12: "Always think 3 steps ahead."
Whatever you do, do not do it for today or tomorrow, think big: do it for the next years. Meaning always tries to see what is ahead of you and already implement the better solution from the get-go. This also means, try to foresee what might be breaking. For example, when building some code, or server, or a project plan: Add all the extra functionality, monitoring, etc.. that you think we might need next year or the year after. Or at least do it in such a way that this can be added later without too many core changes.
Rule 13: "When the job is done, walk away."
I did not say: run away, but walk away: peacefully. Follow rule-#4 while you do it, however, do not get stuck on one and the same thing when trying to make something super perfect, or implement too many details. Get stuff done, make sure it works properly, then move on to the next thing. Otherwise, we as a team will never get a lot of stuff completed. pro-tip: the more stuff we get done, the more time there will be to revisit your projects later to expand the usability of a previous project.
Rule 14: "Bend the line, don't break it."
Sorry, if you expected me to allow you here to break all company rules, no that's NOT what I'm saying, lol. Again the trick is the balance: do let the “rules” hinder you in implementing/executing ideas (especially proof of concepts), however, most rules are put in place for a reason (security/audit/etc..) so they should not be broken. Practically, however, rules should not be set in concrete, meaning that situations might change and this might also force a rule-change. Remember: part of rule-#1 is to challenge everything.
Rule 15: "Every answer should raise 2 new questions."
Hardly ever is one answer enough to solve a question. Even in the case that an answer satisfies the question, you apply rule-#12 which will for sure raise more questions.
Rule 16: "Never mess with TechOps coffee... if you want to live."
A bit of fun, but also a bit of truth. We have stuff we need (like tools, information streams, freedom to operate, etc..) that should not be messed with. It should be clear that if people are breaking or neglecting our tools (that applies to ourselves also) this will not go unnoticed and probably will have consequences for the business.
Rule 17: "Keep it simple, stupid"
The logical follow-up of rule-#9. Keep stuff simple and with as little as possible complexity. However, this should be balanced with functionality and maintainability.
Rule 18: "Always watch the watchers."
Who is watching the monitoring systems? More monitoring systems? Can they be trusted? Please do not lose the human element in monitoring. We should always keep watching (and challenge) our technology ourselves (by humans).
Rule 19: "Every question is a valid question"
This one is simple: There are no stupid questions. We are supposed to safeguard our production systems, therefore we should understand everything. (systems, architecture, processes, etc..) If anything is unclear: ASK! Also, ask yourself the question, WHY do I need to ask this question, is there may be a lack of documentation, communication, are certain teams or people working in an isolated way/meaningless error message texts? Most of the time these answers provide you with the reasons as to why even your “stupid” questions are actually valid.
Rule 20: "If you feel like you are being played, you probably are."
I’m NOT saying that your colleagues are on purpose trying to trick you, but company politics might. We are the last line of defense for safeguarding our production systems, sometimes people might not want you to see something or deep-dive into something in the fear you might detect oversight or incompetence, or uncover an honest mistake. Referring to Rule-#30: we will figure it out. It is our job to be suspicious of everything.
Rule 21: "Your ticket, your lead, your responsibility."
This is our version of the value: “Own it”. You start something (or get something assigned to you/your sub-department) you will own it from start to finish. This means, planning/executing/documenting/monitoring/coordinating/post task follow-up/etc.. and applies to tasks/responsibilities/incidents/requests/etc.. Pro-tip: This does not mean you have to DO it all yourself. We have set up TechOps in such a way that we can work together in split expertise or responsibilities, and also we should delegate sub-tasks to other departments. However, YOU are in control of the end-to-end process and should be aware of what is happening every step of the way.
Rule 22: "There is no such thing as coincidence."
Technology is following human instructions (code, operating systems, etc..) and this is true also on the side of our customers & products. So everything in our production system is happening for a reason, even if it’s not immediately apparent. Find it!
Rule 23: "First things first, start with your biggest Y."
Something borrowed from the 6-sigma method: The first thing you always should do is to identify your biggest Y (WHY), so you know where to concentrate your effort in order to archive the biggest effect with the lesser effort. After having done so, you re-assess (measure/monitor/research) to find the new biggest Y (in most of the cases it’s the next smaller problem. Unless you broke something and created an even bigger problem.
Practical example: “10k warnings per 7days in Kibana”
Find the message that shows up the most amount of times (eg: 4k), Then fix it. Wait a couple of days, then look at the remaining problems and repeat.
Rule 24: "he who doesn't make mistakes, is not doing any work"
This one is as old as times: You cannot make mistakes when you are not doing anything. Once you start doing any work, you will also start making mistakes. This is totally normal and perfectly fine. If your work ethic/process is correct you will find them in time they do any serious harm. Fix it and clean up is the right thing to do. Hiding your mistakes and not telling anyone about them is the wrong thing to do. If you have a good manager he/she will understand that mistakes are normal and will not judge you for it. Unless you make these mistakes all the time or don't find or correct them once you do, because that's just being tardy or ignorant. In short: mistakes happen, be fair about it.
Rule 25: "avoidable mistakes are easily avoided."
Rule-#24 is not an excuse to make a lot of mistakes. There are several ways to avoid making them. Add fail-safe processes into the way your work. (following these principles is a good start).
Rule 26: "pull before you push."
Something that was taken from GitFlow that applies to being a human also. Before you push your opinion/ideas/plans/etc.. onto other people or departments, ask them some probing questions in the same direction. You will find that this helps identify their needs and make them more open to what you are going to push.
Rule 27: "Chances are that the wheel has already been invented..."
I did hear about this concept “wheel” before, so probably I can skip creating one today. Before starting something new, maybe someone else already has part(s) of that you need is thus you might be able to save a lot of time. Also, chances are that the wheel that already exists has a few design features that will eliminate a lot of the most common errors/mistakes. learn from them!
Rule 28: "Clean up the mess that you make."
Maybe also a part of rule-#24 & rule-#21. Once everything goes tit’s up, it’s up to you to not only make sure the issue gets fixed but also that whatever impact the issue left behind gets cleaned up. Again as always: feel free to ask for help doing so, but guess who is responsible for the overall clean-up?.
Rule 29: "Never trust a running system: fix it till it's broke"
Don't stop troubleshooting/fixing/asking questions/etc.. at the first success/answer/solution. Dig a little further, maybe even past the comfort levels. Only once you understand the complete situation, you will be able to deal with it.
Rule 30: "Keep digging till you hit bottom."
Yeah sure, ofc we will not keep working on a system until we break it. Our mission is to keep stuff working: duh. However, our monitoring gene should intuitively tell us not to trust a running system. How many deployments are we past our known good? which super rare factor has triggered an exception that is not handled correctly? Is there any external influence to have caused this previously unknown bug to show itself? Our ticket shows we upgraded this software, but did we really? Is there forgotten automation in place that did something we didn't expect to happen? Did we change the behavior of something, or did we re-purpose something without removing the old code or configuration?
Rule 31: "The world outside your BOX is large."
Think outside the box, invent new things, any idea is valid, nothing is too crazy. Even the craziest ideas or jokes might lead to a valid new way of doing things. This is the way how we can keep innovating and improving ourselves outside of copying what others are already doing.
Rule 32: "Where's my money? (think about the money-flow)."
Very specific to the financial industry, but none the less super important. Before changing any configuration/code/server setup etc.. take a second to think about how your change could impact the money flow of our products and or settlements. This might prevent you from making very embarrassing mistakes. Probably “the flow” is also valid for most other businesses, it would be a bit of an issue if you open the wrong pipeline and deliver oil to the wrong country, or sending files to the wrong server etc…
Rule 33: "404: TechOps has eaten all your cookies."
This rule is mostly fun, but please be free to bring us some (chocolate) cookies, we love them!
Rule 34: "Syntax error: emotion is not a valid function"
Abstract yourself from any emotion and let your actions be driven by facts instead. Sounds easy enough right? Think about it though!
Rule 35: "Do it today as tomorrow never comes"
Tomorrow never comes. Janis Joplin discovered this on a train once. Because tomorrow, tomorrow is again tomorrow, and not today! Basically meaning “make it so” but, make it so TODAY! Tomorrow is very far away and whatever you plan for tomorrow will be long forgotten when that day finally comes.
Rule 36: "Keep calm and read the logs"
Do not panic, collect your facts, be assured there is always someone that can help you or provide information. In terms of TechOps: take your time and do some initial troubleshooting first by reading and understanding the relevant data available to you. Then take action from there. Not only is this a better way to do things for your own sanity, but you will also find this to be the quickest and most reliable way.
Rule 37: "TechOps is the last resort: NO does not exist"
People turn to us because they have nowhere else to go. TechOps should always have the overall picture and access to understand and fix things. Other departments might have a lot of expert knowledge, but they probably lack the total overall picture. We should, therefore, deal with every request and take ownership of finding a solution/answer. This probably entails that we work with the expert departments in order to validate solutions or execute actual changes, but in the end like always, we should own the request until the requesting party is satisfied.
~$Contact
My online presence
- Gitlab.com
- pressemitteilungen der polizei München: (telegram channel)
- Tweakers.net nieuwsfeed: (telegram channel)