Stay focused on the engineering reality defined by your capabilities and requirements. Line up the engineering tasks with the business value. A shift in the engineering tasks should be a conscious decision as a result of conversations between the technical and business leaders in order to better deliver on the business value. Technical debt can be discarded when the engineering objectives change. Remember all technology is transient and that pride cometh before a fall.
Given all that has passed and is pressing,
Shown beneath this velvet veil of night;
Shallow do these words now feel from this breath,
Small these thoughts held against your might.
Deep the wellspring of these flighty thoughts,
Ardent arrows of dreams their flight do aid;
If only one should land upon your fiery brow,
This task would stand completed.
This day that dawns a thousand sighs unbounded,
Should leave so barren a bosom as mine;
There across Hercules seas should flash,
Hermes’s wings could barely keep apace.
Glorious in splendour lift up your eyes,
The days of your future stand ready to unfurl;
Beneath what skies none may yet say;
To you alone time listens,
There are somethings that I dislike. The image above is a screen capture from a conversation I was part of recently and said by someone who I respect deeply. On this point, we disagree deeply however.
Modern DevOps culture demands a great deal of pragmatism. In particular it demands that you don’t solve problems before they become problems. It’s the benefit of working in a non-critical environment. We’re told that ‘just-in-time’ is the best fit for fast iteration and product development and who can argue with success? I wonder however if we’re losing a key component of good Engineering, that of forethought.
The conversation was around GitHub protected branches and whether they were a good idea for some/all our repo’s. I think these are a good idea for all repo’s and selected branches, especially master, and doesn’t take long to setup nor much in the way of maintenance or documentation. I can also understand my colleague’s position that there’s no need to go enable this everywhere as nothing bad has happened yet that would suggest this would be a good protective measure.
To me that’s a bit like putting the safety on after pulling the trigger. The thought’s there but the execution is suspect. It’s too Dev and not enough Ops for me.
In operations/SRE or whatever you call it these days, the paramount responsibility is safety. Safety leads to uptime. Uptime leads to sales. Sales lead to money. Money leads to wages. Wages lead to whiskey. Operations engineers are there to make sure that the business is supported and protected at all times. Operations engineers are there to ensure that engineering is able to deliver but that the what’s delivered is supportable and operable on an on-going basis – even if the entire engineering team changes. There is I think a fine distinction here between enabling the business and enabling engineering teams. Those two enablements often require subtle differences in approach, tact and execution. It’s the fine line that sometimes trips you up.
On this occasion I left this well alone, no one needs this kind of debate on a Friday and it’s a small thing. But small things have undone great enterprises before so in the back of my head a warning bell will sound all weekend! I like to think I allow teams I manage a great deal of autonomy and the operations team haven’t expressed any concerns. Whether that’s because it’s easier not to is up for debate – but not today.
The leaves of the tree are green,
In the hole in the bole of the tree lives a very old mole that was lost you see!
He went to bed when he was a sleepy head,
Come rain or shine,
Summer and winter,
He would not budge,
He would not move!
So no one could ever see him – you see!
– Constance O’Connor
One of the issues of using public GitHub is that, well, it’s public. Even with the layers of security, it’s all your information ‘out there’. Somewhere.
However, it is a fact of life that we all use GitHub and many large and small companies choose the hosted GitHub option over hosting an in-house, expensive GitHub Enterprise environment. The problem is that developers and operations folks sometimes push things into GitHub without thinking. How about those keys or passwords you’re meant to use Ansible Vault or StackExchange blackbox for but didn’t?
With this in mind someone on the internet wrote gitrob to try and provide some kind of insight into what you may or may not be storing in your vast, sprawling, micro-services hell of repos. It’s pretty neat and all but we’re a docker house for better or worse and we wanted it packaged neatly for us. To that end we created a docker image for gitrob and how we use it at TES Global.
In essence, using docker, you can run a container as the main backend service while running a scan container on a cron job to keep the information updated. This works well for us, but your milage will vary. You will need Postgres and a GitHub OAuth token in order to get this to work. See the README.md here for more information.
By the way, all we did was dockerize this – much kudos to Michael Henriksen for gitrob!
I am an Engineer
I work for TES Global. TES Global’s story is an extraordinary one: its digital community on TES Connect is one of the fastest growing of any profession globally, and it boasts a 100-year heritage at the centre of the teaching and education community, with offices in London, San Francisco and Sydney. Today, TES Global has over 6.9 million teacher members in 197 countries across the globe and connects more than 72 million teachers and students. Up to 6.3 million resources are downloaded from the site a week, 13 a second. Home to more than 800,000 individually crafted teaching resources developed by teachers for teachers, this unparalleled collection helps to guide, inform and inspire educators around the world.
The operations team at TES plays a big part in ensuring our platform is kept alive and healthy as well as working very closely with a range of developers to deliver one of the smoothest delivery pipelines I’ve had the privilege to work with. I’m now looking to expand my team and am looking for an individual who has current permission to work in the UK and will not require VISA sponsorship to join us as a Senior Platform Engineer (SPE).
SPEs are responsible not only for the underlying hybrid cloud infrastructure but also for networking, security, performance, automation, integration and education of the wider internal developer community in the best practices of using our infrastructure and services. They are the last but one line of support and assistance and as such are expected to understand their subject matter deeply and thoroughly. It can be an incredibly challenging role but one that we all feel is worth doing and worth doing well. We all work in an Agile manner and believe in effective communication as the single most important tool at our disposal.
The TES platform lives within the AWS public cloud and an internal Xen based stack. SPEs are expected to be deeply familiar with both these stacks and to provide interfaces for developer operations that are seamless between the two.
We make extensive use of Docker, Ansible and Python and our SPEs are expected to be familiar with these technologies and to become extremely proficient with them. You’ll be supported each step of the way on that journey.
We work closely with the wider engineering teams to share our experiences and knowledge to continuously improve the technical operations procedures, tools and approaches throughout the business.
What’s it like to work here?
We release regularly and frequently here at TES and that means our systems and our infrastructure has to be as dynamic and robust as the engineers creating the features. This isn’t a 9 to 5 job and we work the job and not the clock. TES values it’s people highly so there are various social events regularly scheduled to help maintain a healthy atmosphere and a sense of community. We try to hire clever people to do simple things and so make the complex seem mundane.
We constantly look at ways we can improve how we work to cooperate and tune the process to the people rather than the other way around. We don’t believe in blindly following doctrine but encourage teams to arrive quickly and effectively on ways of working that help deliver the quality our customers have become accustomed to.
We’re no strangers to trying edge things and our CTO, Clifton Cunningham, allows us all the freedom to experiment responsibly in order to drive our innovation with many of us having worked with him a number of times before. There’s a reason for that.
- Providing input into any new solutions and for any enhancements of existing ones.
- Working with Agile development teams in a web facing environment and for mentoring junior developers in the DevOps process.
- Driving and owning relationships with multiple suppliers and internal teams.
- Driving continuous improvement across multi-disciplined teams.
- Help establish, renew and run processes for on-going maintenance and monitoring operations within the platform.
- Providing out of hours on-call services on a rota basis.
Candidates should have experience of working in large scale, highly available enterprise environments and have demonstrable capabilities of contributing to a large scale python project. Experience should include some or all of the following technologies;
- Linux Networking
- Hadoop / RDS / MapReduce
- Git / npm / dpkg / apt
- Docker / Docker Swarm
- Rancher / Messos / Marathon / Kube
If you’re looking for somewhere to grow your skills and career and not just another job where you can hack then we’re probably going to get along fine. We’re very interested in any female engineers who might want to consider this role to help bring balance to the force.
There will be a technical test to pass as well as some tests that you won’t think a technical role would require. We’re looking for the whole of you and not just your technical kudos so come with an open mind.
If you’d like to talk about this role then please get in touch with me at email@example.com with a current CV and GitHub account.
Well this baffled be for a few minutes and I’m really just capturing this for my own knowledge later. If this happens to you it’s most likely your network password has changed or expired or something. Get it reset and then use your Keychain Access app and locate the printer name. Re-enter the password and you’re good to go.