System administrators and web site reliability engineers (SRE, same below) are important to any organization. This article will explain the differences between the two.

In the IT industry, being a generalist or expert has always been controversial. 99% of traditional system administrators fall into the generalist category. The role of site reliability Engineer (SRE) is more specialized and is in increasing demand in head companies of a certain size such as Google. But in general, both have the same goal for running app infrastructure: to provide a great experience for app consumers. But their starting points are very different.

System administrator: The embodiment of neutral goodness

System administrators typically grew up with basic desktop or network support and along the way acquired a wide range of skills that most system administrators have. At this point, these system administrators will be familiar with the systems and applications they are responsible for. They know that the application on server 1 needs to be restarted every other Tuesday, or that server 9 crashes silently on Wednesdays. They fine-tune the server’s monitoring to ignore irrelevant messages, although the error message marked as fatal is displayed every third Sunday of the month.

In general, system administrators know how to take care of the servers that run your core business. These system administrators have grown to use automated tools to handle routine tasks on all the servers they manage. They like to use templates, golden images, and standards, but are flexible enough to modify parameters on a server to fix errors and comment on why that server is configured differently.

Great as they are, system administrators have some quirks. One is that you can never get root access to the system without their divine authorization, and the other is that any changes that are not their idea are documented as requested by the application provider and still need to be double-checked.

The servers they manage are their domain, and no one can interfere with them.

SRE: Thanos will be proud of it

As opposed to the path of becoming a system administrator, the likelihood of growing from a development background to an SRE is similar to that of growing from a system administrator background. SRE positions occur for a similar period of time to the life cycle of the application development environment.

DevOps concepts like continuous integration and continuous publishing (CI/CD) are introduced as an organization grows, and there are often skill gaps to allow these immutable immutable applications to be deployed to multiple environments and to scale as business needs arise. This will be the stage for SRE. Yes, a system administrator can learn additional tools, but by and large it’s easier to follow up on a full-time position. A specialist makes more sense.

SRE uses concepts such as code, infrastructure infrastructure-as-code, to create templates, and then calls them to deploy the environment to run the application, with the goal of recreating each application and their environment completely with one click. Thus, the binaries of application 1 on server 1 in the test environment are exactly the same as those of server 15 in the production environment, except for environment-related variables such as passwords and database link strings.

SRE will also completely destroy an environment and rebuild it when the configuration changes. They have no emotional attachment to any system. Each system is just a number marked and scheduled for life, and even routine server patching involves redeploying the entire application stack

conclusion

In some cases, especially when operating large DevOPs-based environments, the expertise that an SRE can provide to handle businesses of all sizes is certainly advantageous. But every time they hit a dead end, they turn to their sys-admin buddy or BOFH from hell for help with his time-tested troubleshooting skills and extensive experience that provides value to the organization.

Via: opensource.com/article/19/…

By Vince Power, Lujun9972

This article is originally compiled by LCTT and released in Linux China