Thomas의 Cloud Engineering

DevOps 에서는 개발자가 운영자가 된다. 물론 24시간 대응하는 티어그룹이 따로 있을 수는 있지만 결국에 원인을 분석해서 이슈를 수정하는 책임은 보통 개발자가 된다. 이슈가 많아지면 개발자는 고통받는다. 심지어 개발팀이 정상적인 개발업무를 수행하기 어려워진다. 보통은 온콜(oncall) 프로세스를 도입하여 당번제 처럼 돌아가면서 한두명의 개발자가 들어오는 CS나 이슈를 모두 처리하도록 하여 다른 개발자들이 개발에 집중할수 있도록 한다. 하지만, 빈번히 발생하는 이슈를 계속해서 온콜로만 대응하다가는 개발팀의 효율이 개선되지 않는다. 그러므로 운영에 있어서 자동화와 최적화는 지속적으로 이루어져야 한다. 자동화의 범위 어느정도 게으른 개발자가 되라는 얘기가 있듯이, 개발자는 항상 개선을 고민해야 한다. 그..

그 동안 여러 그룹 스터디를 해보면서 효율적인 방법에는 어떤 것들이 있는지 개인적인 의견을 얘기해보고자 한다. 스터디 빈도나 시간 등은 별로 상관이 없는거 같고, 스터디 진행 방식, 발표 준비/방식에 대해서만 말하고자 한다. 진행 방식 스터디 동기부여가 중요하다. 그냥 보겠다 라기보다는 왜 해야하는지를 스터디 멤버들이 잘 이해하고 있어야 한다. 가장 좋은 동기부여는 업무와 관련된 것이다. 그리고 그 업무내용을 공유해 볼수 있어야 한다. 스터디 시간의 절반은 발표를, 나머지 절반은 자신들의 업무에 관해 토론을 해보는 것이다. 인원이 10명이 넘어가면 스터디 효과가 떨어진다. 이럴 때는 과감히 그룹을 두개 이상으로 나눠야 한다. 다만 이렇게 하면 그룹별로 사일로가 생기기 때문에 그룹을 계속 섞어줘야 한다. ..