Your IT team knows your business. They know why the reporting system matters on a Monday morning, which application the finance team relies on and what happens when an overnight process doesn’t finish.
That’s essential knowledge for the business. It doesn’t follow that they also need to spend their time investigating Linux alerts, planning operating system upgrades and checking why a filesystem’s filling up again.
Linux support for internal IT teams can give you specialist help with the platform while your people keep looking after the applications and users they know. To make that work, the conversation starts with what each team will own, and how they’ll work together when the answer isn’t immediately obvious.
You don’t have to hand over everything
Bringing in a Linux support partner doesn’t have to mean replacing your internal team or moving your servers somewhere else.
A common arrangement at Tiger is for your team to manage the application while we manage the Linux platform underneath it. Your developers keep their knowledge of the code, releases and business requirements. Our engineers take responsibility for the agreed Linux environment.
The detail depends on your systems. A database, for example, needs an explicit place in that arrangement. Software supplied with the Linux distribution normally falls within our agreed platform scope; other open-source components need assessment. Commercial applications may need their vendor involved, and custom applications remain with their developers.
We work that out with you. Nobody benefits from discovering, halfway through an incident, that everyone thought someone else was looking after the database.
Clear ownership makes it easier to work together
“We both look after the server” sounds collaborative. It can also mean two teams changing the same configuration and neither being entirely sure what the other has done.
We agree an owner for each part of the environment. If Tiger manages the Linux platform, your team works with us on changes to that platform rather than independently changing the same components.
That gives your developers someone to discuss requirements with. If a release needs a different package, more capacity or a configuration change, they can explain what they’re trying to achieve. We can work through the implications and agree the change together.
It’s much easier to investigate a problem when the configuration history doesn’t contain a surprise contribution from someone who was “just trying something”.
The application’s slow. Whose problem is it?
Imagine users are reporting that an application’s taking too long to respond. It might be the code. It might be a database query, storage performance or pressure on the operating system. At that point, assigning blame isn’t a particularly useful diagnostic tool.
Your application team brings its knowledge of the software and recent releases. We investigate the agreed Linux platform and share relevant findings to help establish what’s happening. Where another supplier needs to be involved, we work across that boundary too.
Clear responsibilities should help the investigation move forward. They shouldn’t turn it into a series of tickets saying “not ours”.
Before there’s a problem, agree how the teams will share findings, request changes and involve the right people. If a change needs approval, everyone should know who can give it. Those small practical decisions save a surprising amount of time later.
Agree the cover as well as the responsibilities
If your team’s stretched, it can be tempting to think of external support as someone who takes over the same platform when everyone else is busy. However, “filling in” isn’t really a good way to make a Linux support partnership work.
At Tiger, we agree consistent ownership of the managed Linux platform, with engineer response during the support hours you’ve chosen. We don’t independently manage the same operating system in shifts with your internal team.
Supported systems are monitored 24/7. Engineer response follows your agreement, whether that’s business hours, extended hours or round-the-clock cover. Monitoring overnight doesn’t automatically mean an engineer will respond overnight, so if your cover is just for business hours will address anything that cropped up overnight in the morning.
Tell us when your systems matter to the business. An overnight process or weekend service can change the conversation about suitable cover, even if most of your staff work nine to five.
Give both teams a clear view of the work
Your people should know what’s covered, how to ask for help and where to follow an issue.
TigerEye, our online client portal, gives you access to support tickets, summarised system utilisation information and your support schedule, including the systems covered and your contacts. Alongside direct contact with our engineers, it gives your team a practical way to keep track of support.
We also review the service with you, so changing requirements and recommended improvements can be discussed before they become urgent.
When a request falls outside the agreed support, we’ll explain that and agree the work separately. We don’t start chargeable work without written approval. Keeping the existing platform running and asking it to do something new aren’t always the same piece of work.
Backups need the same clarity. Configuration backups are included in Tiger’s support; data backups are separate. Agree who protects your files, databases and application data, and how recovery will be tested. It’s a short conversation with potentially rather long consequences if nobody has it.
Start with where your team needs help
You don’t need a finished responsibility chart before talking to us. Tell us what your team wants to keep looking after, where Linux is taking up time and which systems you depend on.
We can talk through the business problem or get into the technical detail with your engineers. Either way, the aim is to give your people confidence that the Linux platform is being looked after, with someone they can work with when requirements change or things don’t behave as expected.
Explore our managed Linux support, or read the Linux support FAQs for more about how we work.
If you’d rather talk it through, tell us where your team needs a hand.
