Chapter 1 리뷰~

"책 내용을 다 정리하는 것이 아니라, 읽고 나서 생각했던 점을 적는 짧은 리뷰"

 

구조

#키워드

{

내용

}

 

 

#문제점 : 개발자가 코드를 만든후, 운영팀에게 대충 던져 놓고 간다.

{

공감이 정말정말 크게 되는 문장 같았다. 이상적이지 않게도, dev 와 ops는 서로 Adversarial한 관계이기 때문에, 책에서 나온 삽화 처럼 개발자가 코드 만들어서 벽 너머로 던지면, 서버에서 코드 실행 ⇒ 안되는 구조를 실제로도 띄게 된다.

 

dev : 인터넷 안돼. 내 pc에선 된다니까? 니가 만든 인프라가 문제잖아?

ops : 아니 인터넷 연결 해놨다고, 니 코드가 문제라니까?

 

실제로 우리 회사에서 수도 없이 많이 일어나는 일이다.

 

서로 싸우느라 고객에게 양질의 서비스가 제공되는건 어느새 뒷전이 된다.

 

그 무엇보다 중요해진 “내 책임 아냐.”

 

심지어 우리 회사는 Dev 업체와, Ops 업체가 같이 일을 수주받은 완전히 다른 기업이다.

 

- 일이 실제로 이렇게 돌아간다.

인프라를 만들면 어떻게 설계되어 있고 당신의 로직이 이렇게 운영됩니다. 하고 설명하는게 아니라

⇒ 우리 만들거 다 만들었다고 전화해. (실제로는 되는지 모름)

⇒ 그러면 쟤네들이 몇일 삽질하다가 안돼면 안된다고 전화할거야. 그럼 우린 몇일 시간 버는 거야.

이런걸 보면서 이 책을 읽으니까

아, 이래서 Dev 와 Ops가 같은 팀이어야만 하는 구나.

 

하는 생각을 참 많이 했던거 같다.

}

 

#immutable infrastructure

{

이 부분 역시 읽으면서 정말 많이 공감을 했다.

 

회사에서 mutable infrastructure로만 운영이 되니까.

 

심지어 코드를 수동으로 배포하고, 개발자, 운영자, 보안팀, 원청, 고객 등이 언제 들어와서 작업하고 나가는지 모르니까

조금이라도 구조를 변경하고 싶다면,

 

무조건 인스턴스 하나를 통으로 백업한다.

⇒ 그래서 실제로는 아무 변화도 없었는데도 누가 건드렸을지 모르니 저장하자! (세이브를 생활화해!) 이런 이유로 백업을 할때 정말정말 많다.

 

그리고 누가 건드리다가 인프라가 날아가면 모두가 멘붕한다.

바로 비상 터지고 5~6시간 이상 회의실에 단체로 모여서 하루종일 수정한다.

 

그리고 개발자들이 자기 코드 왜 안되는지를 몰라서 보안그룹을 운영팀 몰래 열어서 테스트를 하고 복원을 안해놓을때가 정말 많다.

⇒ 사실 테라폼 쓰면 그냥 다시 apply만 해주면 끝나는 부분이다.

}