What is an SRE?

A theoretical explanation of SRE will be omitted. If you do a search, you will come up with much better articles. I will briefly describe my thoughts here. This article is just a personal opinion about the things I’ve been thinking about lately, and it’s clear in advance that it’s not an established theory.

SRE stands for Site Reliability Engineer. This is what Google’s DevOps organization first started calling it. Much of what SRE and DevOps do overlap. But the reasons for doing it are completely different.

The focus of DevOps is the improvement of productivity of the development organization and the automation of distribution/operation. However, SRE’s concern is service stabilization. What needs to be done for service stabilization overlaps a lot with what DevOps does for productivity improvement and automation.

SRE is also developer. It is different from System Engineer who manages infrastructure. System Engineer’s competency is also important for SRE. A lot of relevant knowledge is required to work for service stabilization. However, you need to master the Backend Technique just as much as this. It is also necessary to directly modify the server code to stabilize the service. In addition to these hard skills, the really important thing is the soft skills. Strategies necessary for service stabilization must be formulated, and a company-wide consensus on these needs to be formed, and efforts to keep this must be persuaded and guided by all members. For stability, the mobile app may need to be modified, and the server code may need to be modified. In some cases, the SRE directly hands-on this, but since the SRE cannot do all service codes, it may be necessary to ask the person in charge. In this case, it affects the development of features, so it is possible to persuade the Project Owner or Scrum Master.

However, in Korea, SRE is used as a more sophisticated word than DevOps, and it is unfortunate that only hard skills are mentioned in job postings.

The first thing that comes out of what SRE do is setting SLO (Service Level Objective). Strategy and analysis are also required in setting SLOs. Achieving a high SLO is costly. There may be infrastructure maintenance costs such as redundancy, but in order to protect this, the things that developers have to follow become stricter, there are a lot more things to consider when deploying, and in a more complex system, a more complicated rollback process, all of these are costs. Therefore, it is not good to set the SLO unconditionally high. And there are many cases where SLOs are set that are impossible in the first place. For example, if you set the SLA to 5-nines (99.999%), the allowed downtime per year is 5m 13s. But what if you deploy every week in a system where about 10s of downtime occurs due to the timing of DB Migration and Server API distribution every time you deploy? Or what if an alarm that can detect failures is set to notify within 1 minute of the distribution time, and it takes 2 minutes to roll back the server in a failure situation? Does that mean only one foreseeable failure per year is allowed? Setting the SLO also requires a strategy. Cost, developer fatigue, and service characteristics should be considered.

In terms of wired/wireless service, the three mobile carriers stipulate that compensation should be paid if the time of damage caused by a communication failure is more than 3 consecutive hours or if the monthly cumulative time exceeds 6 hours. - 2021.10.29 article

In the case of mobile app services, should we strive to achieve a higher level of SLA than the carrier’s SLA? What efforts should be made to do so? For example, what efforts should be made for users who use SKT? It is very difficult to strive for a higher SLA than this. What is the probability that the disk will fail? For a higher SLA, the disks must be duplicated.

So how should you strategize?

First, risk analysis and safety net should be established.

• Analysis of risk factors that hinder service stabilization
• Envision ways to prevent or reduce risk. composition again. envisioned in many ways.

All humans make mistakes. Expecting no one to make mistakes doesn’t really work. Even if someone makes one mistake, you need a mechanism to be aware of it before it is reflected in production from a different angle and prevent it from reaching you.

These are the words of Goodoc CTO.

Each safety net should also be analyzed in terms of importance and cost. Of course, each safety net is fine. You can’t do everything though. How much revenue does our service generate? How much revenue does the service generate per user? What is the impact on users when a failure occurs? analysis is needed. So you have to think about whether it is reasonable to spend more effort or cost than this. And over time, new hazards will arise, and then you will need to devise new safety nets for them.

It is difficult for all safety nets to become an automated system. It can be the improvement of work process, the definition of a specific role and the recruitment of personnel. There is also a way to introduce a system such as on-call engineer rotation. But much of it will be automated. What you do here overlaps a lot with what DevOps does.

Perhaps one of the above safety nets is Monitoring & Alarm. Then, it is necessary to know how to know the failure of each service. Should we actively monitor? Is there any way to notify by alarm? So, how much time do we need until we know after a disability? Is there any way to further reduce this time? You have to think about it in this way.

And the time it takes to recover this in the event of a failure must also be calculated. Is there anything that can be automated in the process? If automated, how long will it take? If you do it manually, is it possible to do it manually? How long does it take if you do it manually? Is there any way to reduce this?

Based on the items listed above, we set an appropriate SLO for our service. This process does not end as a one-time event, but it is necessary to re-analyze risks, think about safety nets, and change priorities in ever-changing situations.

Broadly speaking, I think the above listed tasks are the main tasks of SRE. If you go into detail, there are so many things to consider that I can’t put it all in a short article. This can be seen in detail in the SRE book.

한글로 작성된 원문은 아래에 있으며, 먼저 구글 번역기를 이용하여 영어로 번역한 내용이 있습니다. (The original text written in Korean is below, and first, there is a translation into English using Google Translate.)

SRE 란 뭐하는 사람일까?

SRE에 대한 이론적인 설명은 생략하겠다. 검색하면 훨씬 더 좋은 글이 많이 나올 것이다. 여기서는 나의 생각에 대해서만 짧게 서술하겠다. 이 글은 내가 최근에 고민한 것들에 대한 개인적인 의견일 뿐 정설은 아님을 미리 밝힌다.

SRE는 Site Reliability Engineer의 약자이다. 이는 Google의 DevOps 조직에서 처음 부르기 시작한 말이다. SRE와 DevOps가 하는 일의 많은 부분이 겹친다. 하지만 그 일을 하는 이유는 완전 다르다.

DevOps의 관심사는 개발조직의 생산성 향상 및 배포/운영의 자동화이다. 하지만 SRE의 관심사는 서비스 안정화이다. 서비스 안정화를 위해서 해야할 일들이 DevOps가 생산성 향상 및 자동화를 위해서 하는 일과 많이 겹칠뿐이다.

SRE도 개발자이다. infrastructure를 관리하는 System Engineer와는 다르다. SRE에게 System Engineer의 역량도 중요하다. 서비스 안정화를 위한 작업에 해당 지식이 많이 필요하다. 하지만 이것만큼이나 Backend Technique에 통달해야 한다. 서비스 안정화를 위한 작업으로 서버 코드를 직접 수정하는 일도 많이 필요하다. 이런 Hard Skill뿐만 아니라 정말로 중요한 것은 Soft Skill이다. 서비스 안정화에 필요한 전략을 짜야하며, 이것들에 대해서 전사적으로 공감대를 형성하고 이걸 지키기 위한 노력을 모든 구성원들이 할 수 있도록 설득 및 지도해야한다. 안정화를 위해서는 모바일 앱을 수정해야 할 수도 있으며, 서버코드를 수정해야 할 수도 있다. 이걸 SRE가 직접 hands-on하는 경우도 있지만, 모든 서비스코드들을 SRE가 할 수는 없기에 담당자들에게 부탁해야 할 수도 있어야 한다. 이 경우 feature 개발에 영향을 주므로 Project Owner나 Scrum Master를 설득하는 일도 있다.

하지만 국내에서는 SRE를 그냥 DevOps보다 조금 더 새련된 느낌의 단어로 사용하면서, 채용공고를 보더라도 Hard Skill에 대해서만 언급이 되어 있어서 안타까운 생각이 든다.

SRE가 하는 일에 가장 먼저 나오는 것이 SLO(Service Level Objective) 설정이다. SLO 설정에 있어서도 전략 및 분석이 필요하다. 높은 SLO 달성을 위해서는 비용이 많이 든다. 이중화 같은 infrastructure 유지비도 있겠지만, 이걸 지키기 위해서 개발자들이 지켜야 하는 것들도 더 엄격하게 되며, 배포시 고려해야할 사항도 훨씬 많고, 더 복잡한 시스템에서는 더 복잡한 rollback 과정 등 이 모든 것들이 다 비용이다. 그러므로 SLO를 무조건 높게 설정하는 것이 좋은 것이 아니다. 그리고 애시당초 불가능한 SLO를 설정하는 경우도 많다. 예를 들어서 5-nines (99.999%)로 SLA를 설정할 경우 1년에 허용되는 downtime이 5m 13s이다. 그런데 배포시 마다 DB Migration과 Server API 배포 타이밍 때문에 10s 정도의 downtime이 생기는 시스템인데 매주 배포를 한다면? 아니면 장애를 알 수 있는 alarm이 배포시기로 부터 1분 이내에 알 수 있도록 세팅을 해놓았으며 장애 상황에서 server rollback하는 것이 2분 걸린다면? 1년에 단 한번의 예상가능한 장애만 허용한다는 말인가? SLO 설정을 하는 것에도 전략이 필요하다. 비용과 개발자들의 피로도 및 서비스 특성을 고려해야 한다.

이통 3사는 유·무선 서비스 약관에서 통신 장애가 발생했을 때 피해를 본 시간이 연속 3시간 이상이거나, 월 누적 시간이 6시간을 초과하면 손해배상을 하도록 규정을 두고 있다. - 2021.10.29 기사

모바일 앱 서비스의 경우 통신사의 SLA보다 더 높은 수준의 SLA 달성을 위해서 노력해야 하는가? 그러기 위해서는 어떤 노력을 해야할까? 예를 들어서 SKT를 사용하는 사용자를 위해서 어떤 노력을 해야할까? 이보다 더 높은 SLA를 위해 노력하는건 무척 힘든일이다. disk가 고장날 확률이 몇%인가? 그보다 높은 SLA를 위해서는 disk를 이중화해야 한다.

그럼 어떤 식으로 전략을 짜야할까?

먼저 위험요소(Risk) 분석 및 안전망을 구축해야 한다.

• 서비스 안정화를 저해하는 위험요소(Risk) 분석
• Risk를 막을 수 있는 또는 줄일 수 있는 방법을 구상. 또 구성. 여러가지로 구상.

인간은 누구나 실수합니다. 아무도 실수하지 않는 것을 기대하는 것은 실제로 동작하지 않습니다. 누군가가 하나의 실수를 하더라도 다른 앵글에서 Production에 반영 되기 전에 인지하여 도달하지 못하도록 할 수 있는 장치가 필요합니다.

Goodoc CTO 바르다 김xx 선생님의 말씀이다.

각각의 안전망에 대해서도 중요도 및 비용 등에 대해서 분석을 해야한다. 당연히 각각의 안전망들은 하면 좋다. 그렇다고 모든걸 다 할 수는 없다. 우리 서비스가 얼마나 매출이 나오는 서비스인가? 사용자 1인당 얼만큼 매출이 발생하는 서비스인가? 장애발생시 사용자에게 미치는 영향도는 어느 정도인가? 에 대한 분석이 필요하다. 그래서 이것 이상의 노력이나 비용을 들이는 것이 합리적일까를 고민해야 한다. 그리고 시간이 흐르면서 새로운 위험요소가 생길 것이며 그러면 그것에 대한 새로운 안전망을 구상해야 한다.

모든 안전망이 다 자동화된 시스템화 되기는 힘들다. 업무 프로세스의 개선으로 될 수도 있으며, 특정 역할에 대한 정의 및 인력채용 등이 될 수도 있다. On-call engineer rotation 같은 제도를 도입하는 방법도 있다. 하지만 많은 부분은 자동화가 될 것이다. 여기서 하는 일이 DevOps가 하는 일과 많은 부분 겹친다.

아마 위 안전망 중 하나로 Monitoring & Alarm이 나올 것이다. 그럼 각 서비스 별로 어떻게 장애를 알 수 있는지에 대해서 알아야 한다. 우리가 능동적으로 Monitoring을 해야하는가? Alarm으로 알려주는 방법은 없는가? 그렇다면 우리는 장애 후 알 수 있을때까지 얼마의 시간이 필요한가? 이 시간을 더 줄일 수 있는 방법이 있는가? 이런 식으로 고민을 해야 한다.

그리고 장애 발생시 이걸 recover하는데 들어가는 시간도 계산되어야 한다. 그 과정에서 자동화가 가능한 것이 있는가? 자동화가 될 경우 시간이 얼마나 걸리는가? 수동으로 할 경우 메뉴얼화가 가능한가? 수동으로 하는 경우에는 시간이 얼마나 걸리는가? 이걸 줄일 수 있는 방법이 있는가?

위에서 나열한 사항들을 기반으로 우리 서비스의 적절한 SLO를 설정한다. 이런 과정이 일회성으로 끝나는 것이 아니라 계속해서 변화하는 상황에 대해서 다시 Risk를 분석하고 안전망을 생각하며 우선순위를 변경하는 일이 반복되어야 한다.

크게 보자면 위의 나열한 일들이 SRE의 주업무라고 생각한다. 세부적으로 들어가면 짧은 글로 다 담을 수가 없을 정도로 고려해야할 것들이 많다. 이건 SRE 책을 보면 자세히 알 수 있다.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)