- 유머가 아닌 펌글, 영상 등 가볍게 볼 수 있는 글들도 게시가 가능합니다.
- 여러 회원들이 함께 사용하기 위해 각 회원당 하루 5개로 횟수제한이 있습니다.
- 특정인 비방성 자료는 삼가주십시오.
| Date | 22/12/30 08:25:29 |
| Name | 그저그런 |
| File #1 | Screenshot_20221230_081856.jpg (2.87 MB), Download : 3 |
| Subject | IT 엔지니어 거품 무는 짤 |
 원제 : 서버점검이 오래 걸리는 이유 PM, PL, 프론트엔드, 백엔드, QA, 운영자 모두 공감 가능한 짤일것 같아서 가져왔읍니다. Mission critical 한 서비스 관련일수록 더 임팩트가 클것 갗아요 ㅎㅎ 1
이 게시판에 등록된 그저그런님의 최근 게시물
|
|
https://aws.amazon.com/ko/compute/sla/
aws high availability 보장 내용에서도 99.99%를 약속하는데, 이건 반대로 서비스가 안되는 시간이 0.01%는 생길 수 있어요 하는거라 1년 서비스하면 그동안 50분 정도는 장애가 있을 수 있으니 양해해 달라는 이야기입니다.
공장의 1분의 비가동 시간이 얼마나 큰 가치가 있는지 모르지만, 중요한 서비스라면 그만큼 비용을 들여서 다중화를 하면 되는데 거기서부터는 기술자는 견적만 내는거고 가격표 보고 그만큼 비용을 지불 할 건지 아니면 그냥 위험을 안고 갈건지 가치 판단은 관리자가 하는건데;
그 공장장은 나쁜 관리자네요.
aws high availability 보장 내용에서도 99.99%를 약속하는데, 이건 반대로 서비스가 안되는 시간이 0.01%는 생길 수 있어요 하는거라 1년 서비스하면 그동안 50분 정도는 장애가 있을 수 있으니 양해해 달라는 이야기입니다.
공장의 1분의 비가동 시간이 얼마나 큰 가치가 있는지 모르지만, 중요한 서비스라면 그만큼 비용을 들여서 다중화를 하면 되는데 거기서부터는 기술자는 견적만 내는거고 가격표 보고 그만큼 비용을 지불 할 건지 아니면 그냥 위험을 안고 갈건지 가치 판단은 관리자가 하는건데;
그 공장장은 나쁜 관리자네요.
위 댓글에서 제가 어떤 선후 착오가 있었는지요?
1) 서비스 다운타임 1분 건에 대해서 위에 적은거 조목별로 풀어서 다시 써 보겠습니다.
a: IDC에서 실제 머신을 관리해도 기기 장애는 생길 수 있고, 클라우드 업체에서 임대를 해도 100% 기동을 보장하지 않는다.
b: 그래서 잠깐이라도 다운타임이 있어서는 안되는 서비스라면 다중으로 보험을 들어야 하는데 거기에 비용을 얼마나 쓸 것인지는 기술자는 가격표 견적을 뽑는거고 상급 관리자가 리스크 관리 비용을 얼마나 쓸 건지 결정하는거다.
c: 공장장이 비가동 1분에 대해서 ... 더 보기
1) 서비스 다운타임 1분 건에 대해서 위에 적은거 조목별로 풀어서 다시 써 보겠습니다.
a: IDC에서 실제 머신을 관리해도 기기 장애는 생길 수 있고, 클라우드 업체에서 임대를 해도 100% 기동을 보장하지 않는다.
b: 그래서 잠깐이라도 다운타임이 있어서는 안되는 서비스라면 다중으로 보험을 들어야 하는데 거기에 비용을 얼마나 쓸 것인지는 기술자는 가격표 견적을 뽑는거고 상급 관리자가 리스크 관리 비용을 얼마나 쓸 건지 결정하는거다.
c: 공장장이 비가동 1분에 대해서 ... 더 보기
위 댓글에서 제가 어떤 선후 착오가 있었는지요?
1) 서비스 다운타임 1분 건에 대해서 위에 적은거 조목별로 풀어서 다시 써 보겠습니다.
a: IDC에서 실제 머신을 관리해도 기기 장애는 생길 수 있고, 클라우드 업체에서 임대를 해도 100% 기동을 보장하지 않는다.
b: 그래서 잠깐이라도 다운타임이 있어서는 안되는 서비스라면 다중으로 보험을 들어야 하는데 거기에 비용을 얼마나 쓸 것인지는 기술자는 가격표 견적을 뽑는거고 상급 관리자가 리스크 관리 비용을 얼마나 쓸 건지 결정하는거다.
c: 공장장이 비가동 1분에 대해서 질책을 했다는데, 상급 관리자로서 기술책임자에게 위험성과 비용 견적을 받고 결정을 했다면 본인의 판단에 따른 책임을 방기한거고, 기술 책임자에게 견적서를 받아 보지 않았다면 권한을 위임하면서 생긴 관리책임을 지지 않은거니 나쁜 사람이다.
2) 서버 점검과 1분 비가동이 같은 건이라 이해하신 거 같은데 저는 별개의 건이라 생각했습니다.
기능 적용하느라 서비스 내리고 배포했다가 오동작 확인하고 서버 다시 내리고 롤백하고 재기동 하는데 1분밖에 안걸린다는걸 저는 상상할 수 없었습니다.
1) 서비스 다운타임 1분 건에 대해서 위에 적은거 조목별로 풀어서 다시 써 보겠습니다.
a: IDC에서 실제 머신을 관리해도 기기 장애는 생길 수 있고, 클라우드 업체에서 임대를 해도 100% 기동을 보장하지 않는다.
b: 그래서 잠깐이라도 다운타임이 있어서는 안되는 서비스라면 다중으로 보험을 들어야 하는데 거기에 비용을 얼마나 쓸 것인지는 기술자는 가격표 견적을 뽑는거고 상급 관리자가 리스크 관리 비용을 얼마나 쓸 건지 결정하는거다.
c: 공장장이 비가동 1분에 대해서 질책을 했다는데, 상급 관리자로서 기술책임자에게 위험성과 비용 견적을 받고 결정을 했다면 본인의 판단에 따른 책임을 방기한거고, 기술 책임자에게 견적서를 받아 보지 않았다면 권한을 위임하면서 생긴 관리책임을 지지 않은거니 나쁜 사람이다.
2) 서버 점검과 1분 비가동이 같은 건이라 이해하신 거 같은데 저는 별개의 건이라 생각했습니다.
기능 적용하느라 서비스 내리고 배포했다가 오동작 확인하고 서버 다시 내리고 롤백하고 재기동 하는데 1분밖에 안걸린다는걸 저는 상상할 수 없었습니다.
1) SLA는 장애를 양해 해달라는 뜻이 아니니까요?
인프라인 AWS가 99.99 가용성을 제공한다고 실제 서비스가 1년에 50분 정도는 장애가 있을수 있다는 뜻이 되는건 아니죠.
밑에 풀어쓰신 내용도 대체로는 동의하지만 실제 운영에서 위험성과 비용견적이 비례하진 않습니다. 이중화로 해결 안되는 장애도 분명히 있고요.
자원이 없으면 장애를 막을수 없지만, 자원만 있다고 장애가 해결되는게 아니라서요. 운영자와 개발자의 실력차이도 요소중 하나이니 저런 질책이 있을수 있다고 봅니다.
2) Picard 글이 하나라서 그냥 하나의 사건이라 생각했습니다. 기능 적용이 2시- 4시인데 4시까지 해결안되고 4시 1분에 해결되면 1분만큼 손해라고 할수도 있을것 같았어요.
인프라인 AWS가 99.99 가용성을 제공한다고 실제 서비스가 1년에 50분 정도는 장애가 있을수 있다는 뜻이 되는건 아니죠.
밑에 풀어쓰신 내용도 대체로는 동의하지만 실제 운영에서 위험성과 비용견적이 비례하진 않습니다. 이중화로 해결 안되는 장애도 분명히 있고요.
자원이 없으면 장애를 막을수 없지만, 자원만 있다고 장애가 해결되는게 아니라서요. 운영자와 개발자의 실력차이도 요소중 하나이니 저런 질책이 있을수 있다고 봅니다.
2) Picard 글이 하나라서 그냥 하나의 사건이라 생각했습니다. 기능 적용이 2시- 4시인데 4시까지 해결안되고 4시 1분에 해결되면 1분만큼 손해라고 할수도 있을것 같았어요.
aws sla 를 예로 들어서 99.99% 고가용성이라도 1년에 50분정도 장애가 생긴다.
=> 그래서 서비스 다운타임이 중요한 경우 다중화 등 추가 작업이 필요하다.
이 부분에서 저는 서비스 하다 보면 1년에 50분 정도 장애 생기는건 어쩔 수 없는 일이니 그냥 참고 넘어가야 한다고 이야기 한 적은 없는데요.
aws sla는 아마존에서 손님들이 손해배상 소송 걸 경우에 대비해 새운 약관이고, aws와 같은 클라우드 서비스를 연장으로 쓰는 경우에도 서비스 장애 관련해서 미리 고려해야 한다고 이야기를 풀어 나갔습니다.
저는 aws 가 100%를 보장하지 않으니 실제 라이브 서비스에서도 마찬가지여야 한다고 주장한 적이 없는데 왜 그렇게 받아들이고 계신지 납득이 가지 않습니다.
=> 그래서 서비스 다운타임이 중요한 경우 다중화 등 추가 작업이 필요하다.
이 부분에서 저는 서비스 하다 보면 1년에 50분 정도 장애 생기는건 어쩔 수 없는 일이니 그냥 참고 넘어가야 한다고 이야기 한 적은 없는데요.
aws sla는 아마존에서 손님들이 손해배상 소송 걸 경우에 대비해 새운 약관이고, aws와 같은 클라우드 서비스를 연장으로 쓰는 경우에도 서비스 장애 관련해서 미리 고려해야 한다고 이야기를 풀어 나갔습니다.
저는 aws 가 100%를 보장하지 않으니 실제 라이브 서비스에서도 마찬가지여야 한다고 주장한 적이 없는데 왜 그렇게 받아들이고 계신지 납득이 가지 않습니다.
1) SLA는 장애를 양해 해달라는 뜻이 아니니까요?
Amazon Web Services 의 service-level-agreements 는 아마존에서 제공하는 기능을 이용하던 손님들이
아마존 장애 때문에 피해를 보았다고 손배 소송을 낼까봐 안전장치로 준비한 약관 같은거라 생각합니다.
'우리가 고가용성이라 하는 건 99.99%로 1년 중 50분 정도는 정상적으로 동작하지 않을 수도 있다.
그러니 우리가 제공하는 기능을 구매해서 사용할 때 이걸 미리 알고 쓰셨으면 한다.' 하고 아마존에서 미리 고시한 내용이지 않습니까. ... 더 보기
Amazon Web Services 의 service-level-agreements 는 아마존에서 제공하는 기능을 이용하던 손님들이
아마존 장애 때문에 피해를 보았다고 손배 소송을 낼까봐 안전장치로 준비한 약관 같은거라 생각합니다.
'우리가 고가용성이라 하는 건 99.99%로 1년 중 50분 정도는 정상적으로 동작하지 않을 수도 있다.
그러니 우리가 제공하는 기능을 구매해서 사용할 때 이걸 미리 알고 쓰셨으면 한다.' 하고 아마존에서 미리 고시한 내용이지 않습니까. ... 더 보기
1) SLA는 장애를 양해 해달라는 뜻이 아니니까요?
Amazon Web Services 의 service-level-agreements 는 아마존에서 제공하는 기능을 이용하던 손님들이
아마존 장애 때문에 피해를 보았다고 손배 소송을 낼까봐 안전장치로 준비한 약관 같은거라 생각합니다.
'우리가 고가용성이라 하는 건 99.99%로 1년 중 50분 정도는 정상적으로 동작하지 않을 수도 있다.
그러니 우리가 제공하는 기능을 구매해서 사용할 때 이걸 미리 알고 쓰셨으면 한다.' 하고 아마존에서 미리 고시한 내용이지 않습니까.
아마존 입장에서 자기들이 제공하는 서비스의 장애 가능성에 대해서 미리 양해를 구하는 내용 아닌가요?
인프라인 AWS가 99.99 가용성을 제공한다고 실제 서비스가 1년에 50분 정도는 장애가 있을수 있다는 뜻이 되는건 아니죠.
저는 "Amazon Web Services" 와는 별개로 [공장의 1분의 비가동 시간이 얼마나 큰 가치가 있는지 모르지만, 중요한 서비스] 에 대해서 aws sla 가 동일하게 적용되어야 한다고 주장한 적이 없습니다.
제가 언급하지 않은 내용에 대해서 반복해서 주장을 하고 계신데 근거를 들어 주셨으면 합니다.
Amazon Web Services 의 service-level-agreements 는 아마존에서 제공하는 기능을 이용하던 손님들이
아마존 장애 때문에 피해를 보았다고 손배 소송을 낼까봐 안전장치로 준비한 약관 같은거라 생각합니다.
'우리가 고가용성이라 하는 건 99.99%로 1년 중 50분 정도는 정상적으로 동작하지 않을 수도 있다.
그러니 우리가 제공하는 기능을 구매해서 사용할 때 이걸 미리 알고 쓰셨으면 한다.' 하고 아마존에서 미리 고시한 내용이지 않습니까.
아마존 입장에서 자기들이 제공하는 서비스의 장애 가능성에 대해서 미리 양해를 구하는 내용 아닌가요?
인프라인 AWS가 99.99 가용성을 제공한다고 실제 서비스가 1년에 50분 정도는 장애가 있을수 있다는 뜻이 되는건 아니죠.
저는 "Amazon Web Services" 와는 별개로 [공장의 1분의 비가동 시간이 얼마나 큰 가치가 있는지 모르지만, 중요한 서비스] 에 대해서 aws sla 가 동일하게 적용되어야 한다고 주장한 적이 없습니다.
제가 언급하지 않은 내용에 대해서 반복해서 주장을 하고 계신데 근거를 들어 주셨으면 합니다.
| 목록 |
|
