Arrived today, hyped!

I have real-world experience with MongoDB, MySQL, Firebase, and caching with Redis.

A colleague in ops recommended this book a while back and I thought I'd give it a whirl to better understand what other options I have available.

I was recuited to do devops work for a client. The project started in late '14. Until mid '15 I was forced to just sit there and do nothing. And I mean nothing. The ops team needed my help but the project lead didn't allow that (endless discussions). Somewhere around the end of '15 I could start to work and quickly learned that I had to report to two leads that couldn't disagree more on what to do and how to do it. I also learned that the companies mentality is "Clean me but don't get me wet". So the ops team demands a lot but is really uncooperative with everything. So I am currently sitting between three grindstones and everything I do is worthless. Because nobody agrees with anybody and I cannot fulfill my job for which I have been hired: Make ops more efficient because they are drowning in manual work. My job is further complicated by the following facts: This company uses no standard whatsoever but their own. Thru this they have created a Rube-Goldberg-Machine. But they think their system is the greatest in the world and the only one that makes sense. Which makes automation pointless because it is not maintainable. They call it diversity and they say that it is the clear reason why automation is not for them even though they schedule meeting after meeting in which they discuss about how to automate things. But in general they do just block everything useful and sabotage my work. And behind my back they make me the reason for the fail. Every real decision is blocked anyway. Also the ops guys think they are the leetest in the world. And everything they invent is above and beyond. If you ask them why they have over 400 VLANs for example (in a company of unter a thousand employees) they stutter and stumble because they cannot explain their complicated shit. They also change their decisions like underwear. Another really "kewl" thing they just did: They hired a devops engineer and everybody loves him. During the interview he said that he has no prior experience with devops whatsoever and it will take him around six month to get started on the basics of devops. I could go on for hours here about the insanity of this company that in my opinion will cease to exist within the next 5 years, if you ask me.
Long story short I am getting out of there by the end of march and will be on sabbatical shortly after because I am burned out. And I mean burned out. Not like "Oh I am burned out". I mean really burned out, with health problems and everything. Another external guy got out here last month because of the same health conditions.

Tonight do not forget to raise a glass to Ops, oncall developers, DBAs and devops, field engineers, warehouse operators. Thanks to them, we can afford to meet the new year properly.

They are working tonight so we wouldn't have to.

Cheers

I'm getting really tired of those dumbass programmers that do not understand shit and then come to me when production breaks. (I am also a programmer, not really a DevOps engineer, but I'm the least worst at DevOps stuff, so it's my job...).

We're programming some kind of document management tool. Today we had a release, and one of the new features is to download all of your documents as a zip file, which is asynchronuously generated. When it's done, the user gets a mail with the download link to the zip file.

The feature works basically, but today it broke our production service, as somebody was running a test of it.

Turns out all the documents are loaded into memory to be zipped. So if you have 2 gigs of documents, a container with memory restrictions in that area will crash.

I asked the programmer who reported this «ops problem» to me, why he didn't just shit the files into a temp foler in order to zip them in there.

He told me that he wanted to do so, but did not know how to mock this for a unit test, and therefore went to the in-memory «solution», which was easier for him to mock.

For fuck's sake, unit tests and mocks are fucking tools, not ends in itself! I don't give a fuck about your pointless mocking code when the application crashes!

When I got to deal with such dumbasses, I'd prefer to mock those motherfuckers with a leaky bucket of liquid shit, which basically accomplishes the same task from my perspective: dripping shit all over the place and make everything suck as fuck.

DevOps is less of Dev and more of Ops. #FML

I no longer work for a startup company. On Monday I’ll start work for a real company, one that values project managers and their infrastructure. As a DevOps engineer, I value the IT resources that power my old companies SaaS platform. My old position is not being back filled and they’re hiring a full time dev instead of and Ops engineer. They have chosen to proceed with zero employees who know Azure or the platform their own software runs on.

Word to the wise when choosing to work for a startup. Ask these questions:

- Do they have a dedicated product manager/owner , who isn’t also the CFO?

- Do they value infrastructure and their IT resources ?

- Do they have decent powered laptops to work with?

- Do they have too much technical debt because they’re always building new features ?

- Do they work 18 hour days because they set poor work/life boundaries ?

- Who handles Support tickets , and what’s a typical support issue like?

- Do they have a branching and merging strategy? Don’t accept “we’re too small” as an answer! It’s a trap that they don’t want one.

In my current company (200+ employees) we have 3 guys who deals with everything related to service desk (format computers, fix network issues, help non-tech people...)

The same team is responsible for the AWS accounts and permissions, Jenkins, self hosted Gitlab... anyway, DevOps stuff.

Thing is: only one of them have enough DevOps background to handle the requests from the engineering team (~15 people). Also, he usually do anything "by hand" clicking trough the AWS interface on each account, never using tools like Infrastructure as Code to help (that's why I started to refer to his role only as Ops, because there's no Dev being done there).

Anyway... I asked my manager why that team is responsible for both jobs, despite the engineering guys having far more experience with those tools. He answered with a shamed smile, as he probably questioned the same to his manager:

- Because they are responsible for everything related to our Infrastructure.

Does it make sense for anyone? Am I missing something here? In what universe this kind of organization is a healthy choice?

"Without ops, it's just code"

Saw a devOps engineer at work wearing a shirt with this quote

Getting real tired of all the ops people referring to themselves as devops

I just finished reading the last chapter of the DevOps Handbook, its an eye opener, but not an easy read. And still recommended.

I've been reading this book for the past year and a half, little by little. It was hard since I started understanding why my work was so frustrating (I'm in System-Cloud-Ops position). The book made sense, while the work did not, it got harder since the book provides solutions, but whenever I dicussed any solutions with management they dismissed everything.
I started to initiate improvements by myself:
Prioritizing tasks I thought were more important to improve the way of work - do now and ask questions later... I got yelled at, I got my managers angry, but afterwards more often then not they admitted I was right.
To make it possible I worked overtime and on weekends, trying to prove a better way is possible, by implementing a long term solutions to solve problems instead of workarounds, automating a lot of stuff, creating labs, preparing presentations and documentation.
Time and time again I tried to pitch more ideas related to DevOps but the managers didn't care...
I know now my burnout started 8 months ago slowly, my hairline started receding, I started clenching my teeth (the doctor said stress was the cause) which was very fainful.
I continued to work but I noticed I was also more cynical, frustrated, and tired.

In the process I neglected myself.
So finally after 2 years and a half I quit my job, to focus on myself, at least for a little while.
I hope in my next job will be better.

So... I'm a DevOps engineer and I received an email from boss today wanting me to do "tech Ops" for next few months, basically tech support because they are having a shortage and too much tickets that they can't handle. *Palmface*

Was once interviewing for Ops support roles looking after multiple websites wrote in java, rails, php with some rest apis, apache, varnish and more....

We were also starting moving towards automation and devops practices so we needed to expand...

We have a great CV from someone who had all of the technologies and chef mentioned on their CV so we were positive....

Invited to interview and something wasn't right..... I dropped a "so you mentioned a few different languages on your CV, can you talk me though some of the applications you've looked after and what languages they were written in, etc?"

His reply.. "yes I looked after a lot of applications and helped people with them in English"

Me "oh.. Okay.... So those apps which software languages were they... You mentioned things like Java and Php and automation tech like chef?"

Him "well yes they were all sorts of things but I predominantly looked after the apps that were wrote in English... Didn't deal with any wrote in java or chef... Just English"

Me ".... Does anyone else have any questions?"

Safe to say we didn't offer him the job....

When companies don't understand what DevOps is and don't know how to implement it.

I hate when the term DevOps gets slapped onto a traditional Ops or sys admin team and they call it a day.

It's become the new agile.

I'm frustrated with an abundance of different *Ops we're having right now. You can spell a random word followed by "Ops", and it's probably a thing. I get that Ops people in general are important but when there is stuff like GitOps, MLOps, FinOps, it gets confusing pretty damn fast. There's no value in all these titles besides "duh" usually, since Ops are just Ops in most situations. They kinda can slap a tracing tool or two on top of your code base but in general they just do Kubernetes (with whatever's hip like Jaeger, etc.) nowadays and that's it. Hell, even "DevOps Engineers", for a majority of cases you'll encounter, are basically just Ops with a misleading prefix since it's just a way people call them nowadays for whatever reason.

I’m currently working with a devops team in the company to migrate our old ass jboss servers architecture to kubernetes.

They’ve been working in this for about a year now, and it was supposed to be delivered a few months back, no one knew what’s going on and last week they manage to have something to see at least.

I’ve never seen anything so bad in my short life as a developer, at the point that the main devops guy can’t even understand his own documentation to add ci/cd to a project.

It goes from trigger manually pipelines in multiple branches for configuration and secrets, a million unnecessary env variables to set, to docker images lacking almost all requisites necessary to run the apps.

You can clearly see the dude goes around internet copy pasting stuff without actually understanding what going on behind as every time you ask him for the guts of the architecture he changes the topic.

And the worst of all this, as my team is their counterpart on development we’ve fighting for weeks to make them understand that is impossible the proceed with this process with over 100 apps and 50+ developers.

Long story short, last two weeks I’ve been fixing the “dev ops” guy mess in terms of processes and documentation but I think this is gonna end really bad, not to sound cocky or anything but developers level is really low, add docker and k8s in top of that and you have a recipe for disaster.

Still enjoying as I have no fault there, and dude got busted.

when operations team doesn't install nano because it is the wrong way to edit text ಠ_ಠ

Me: your SSH wrapper is breaking how Ansible works
Ops: try to use Ansible in another way
Me: your SSH wrapper is breaking how Ansible works
Ops: try to use Ansible in another way
< This goes on for two weeks >
Me: can we please not use wrapper
Ops: we use it to manage ssh keys
Me: this is breaking basic ssh functionality
Ops: OK we are setting up a weird convoluted way so you can run your Ansible playbooks.
Me: ... < doing "it is at least something" dance >

I started working at a new company a couple of weeks ago as a Dev/Ops engineer, my first real ops position after years of being mostly a dev with two sys-admin positions sprinkled in.

I should have seen the red warning signs when, during the interview, a developer told me the old devops team was so bad they fired all of them last year. After I started, I learned that all four people on our team were totally new. Three were hired after the last guy from the old team left (without any notice) and one person use to be a developer who was transferred over to this new team (but not to lead it).

OH: We have a DevOps team that does neither Dev nor Ops. An SRE team that are not engineers and a head of SW Dev who said with a straight face today that our Oracle multi-monolithification over the past 3 years was a ‘Digital Transformation'.

#define DevOps team

- dev team that also does ops or vice versa.
- an ops team calls itself devops but does not actually do development :-|
- IT for developers
- or better to call it SRE team?
...

Hello devrant, so I've been wondering if anyone here breaks things (infosec)? Is there anyone who dabble with building stuff(dev/ops) and breaking them? Need advise whether I should be looking at a devops-y role or a infosec related role in the future. (PS I was in infosec and slowly transitioning into ops/devops not sure yet). Please share your experiences. :)

as a seasoned systems eng myself, i had huge mental block of "i am not a programmer" whining when starting to incorperate agile/infrastructure as code for more seasoned syseng staff.

leadership made devops a role and not a practice so lots of growing pains. was finally able to win them over by asking them to look at how many 'scripts' and 'tools' they wrote to make life easier... and how much simpler and sustainable using puppet/ansible/chef/salt... and checking in all our sacred bin files and only approved 'scripts' would be pushed thru automation tool after post review.

we still are not programmers or developers, but using specific practices and source control took some time but saving us loads of time and gives us ability to actually do engineering

but just have 2 groups of younger guys that grew up wanting to be the bofh/crumudgen get off my systems types that are like not even 30... frustrating as they are the ones that should be more familiar with the shift from strictly ops to some overlap. and the devs that ask for root now that they can launch instances on aws or can launch docker containers and microservice..... ugggg. these 2 groups have never had to rack and stack servers, network gear, storage... just all magic to them because they can start 50 servers with a button click.

try to get past the iam roles, acls, facls, selinux and noshell i have been pushing. bitches.

So being in ops, I have certifications in networking and Linux, and am currently working on my Certified Kubernetes Administrator exam.

I've been talking to a few "professional" (they have jobs) devs that I personally know, and with the exception of 1, it seems like version control, automation, networking, and server related tasks are beyond them.

As I want to get into the dev side of things (devops preferably), I feel somewhat overwhelmed at some of the requirements of the job, especially knowing that I cannot take too much of a pay hit as I have a family to support.

My question is this, based on real world experiences with hiring, how much weight do you think knowing your way around networks, cloud, virtualization, servers, and all of the other things ops does when it comes to getting your foot in the door for a dev job?

I've casually looked around, and it seems that getting the foot in from this side is almost impossible.

For our current project, we connect to three different OpenVPNs:

Our dev OpenVPN (to get Jenkins/Artifactory)
The ops team devops OpenVPN (to get to environment)
The vendor's VPN for single signon

All of them have different keys and one connects to LDAP and uses a password we can't change.

I learned over this weekend that there are no good tape backup systems for Linux. Oh sure, there are a couple of open source projects like Bacula and AMANDA, but they're both a bit too much on the .conf file hell side for me. And fuck literally everything about .tar scripts.

And then you've got things like Backup Exec that, while having its own problems like not being hostable on a Linux machine, will talk to a Linux machine and its connected tape devices with very little hassle.

Linux people: UX is important! Licenses for expensive software are often cheaper than teaching people how to use obtuse systems!

DevOps:

How far does the Ops part go in DevOps? Is it like: Developer are going to manage k8s clusters (with cloud-providers etc.)? Or is it "only" writing deployments etc...?

me: can you help me debug this issue in our artifactory server?
ops: we don't manage that server. devs do
me: can I get access to manage that server?
ops: why would you need access??
me: to manage server ಠ_ಠ
ops: exactly what commands you will need?
me: ಠ_ಠ

Me: [Talking about how you are able to create AMI images on AWS using Packer without relying on public AMI images]
Ops: Yeah our AWS version doesn't have that.
Me: wut? ಠ_ಠ

me: this installation needs swap space on server
ops: we don't do swap space on AWS
me: ಠ_ಠ OK, what other solution can you provide me?
ops: here, use this real (bare metal) server we have
me: will it have all the same access and installed packages I had used on the AWS server?
ops: no, you need to create tickets for that
me: ಠ_ಠ

Making GitLab Ux useable?

We're using GitLab mainly for issue tracking (lots of DevOps, Ops, Oops otherwise), however I find it a bit cumbersome that there's no central way to interact with them.
I have to click through groups and projects to find issues and then go back and forth between the list and each item.

Anybody got suggestions? Am I missing sth? is there a plugin or 3rd party thing?

I just wanna see all issues in the company and quickly check what needs to be done where

We could use sth. else entirely but we currently have so many tools with overlapping features that it would feel kinda stupid

Dear C++ / Java developers.

Please do not write Python, or do utilize helper libraries / pythonisms.

Not EVERYTHING has to be done by hand, it's not CS class anymore. Classes are fine too, not everything has to be passed as comma separated string. Python is proper Object-Oriented language, not scripting tool like Bash.

It's all "Ops" so there's a grey line between "tech ops" and "DevOps" and you can do tech ops easily and have a better idea how to... (Can't remember the right words but what I heard is turn on/off a device)
——Boss, not knowing difference between DevOps and tech support.

My previous job was Engineer ( Ops part of DevOps), supporting the devs with VMs, configurations, dev and test environments, CI maintenance, DBA, DB-dev and such, it was sexy.
In my current company, I have no technical role, but today's task: build a small webpage in sharepoint in HTML.
And the perv part is: it's still bettet than having no Technical task at all...

DevOps With Ruby and Chef on FreeBSD (and Linux)

I am Ops and Dev by heart. I have always automated *nix systems long before any automation framework was invented because I am pretty lazy. Doing stuff more than once manually is just one time too often for me. Imho Ruby is a really elegant language. The same applies for the tools that are built around it. The Chef ecosystem fits into this with its own elegance and stability perfectly because the server is Erlang driven and the rest is Ruby.
Being a Linux and BSD user since the early 90s I have always loved a *nix system for it's concepts and simplicity. One command for exactly one purpose and everything is combineable like letters are combinable to words in my mother language. I have always loved FreeBSD more though. Imho it is even more focused on simplicity. Because it is a really clean approach of system design that envies a base system and keeps 3rd party separated in a clean way for example. It also values classic UNIX philosophies that most Linux distros these days abandon but which saved my life multiple times through better design and execution that also focuses alot more on stability, fault tolerance and ease of use than any Linux I have come across. The hardcore guys should read "Design and Implementation of the FreeBSD Operating System", compare the readings to the Linux way of things and see for themselves.*

*The author acknowledges that this text is his opinion and just his wet dream alone and may not be of any relevance for the sexual lifes of everybody else

I started as a dev. Because corporate wants to save some money for their bonus they put two jobs into one. DevOps is born. Fuck you!

I AM A DEV! LET OPS DO THEIR JOB! I DON'T WANT IT!