MS 클라우드 장애 'IT대란'. 진짜? 난 글쎄??
HTML-код
- Опубликовано: 8 сен 2024
- MS 클라우드 애저의 장애라는 말에 동의하기가 힘들다는 말씀을 글로도 남겨둡니다. 여러 아쉬움이 남습니다. 이 영상은 수 많은 의견 중 겨우 하나의 의견으로 참고하시기를 바랍니다. 늘 고맙습니다. :)
[MS 클라우드 장애 'IT 대란'‥항공·통신 마비]
imnews.imbc.co...
[MS발 먹통 대란에 “빙산의 일각”…취약성 노출한 ‘초연결 세계’]
www.hani.co.kr...
[IT 대란 초래한 MS 윈도…WSJ “개방형 OS 설계가 근본적 원인”]
biz.chosun.com...
[대통령실 "MS 클라우드 장애로 국내 10개 안팎 기업 피해"]
www.news1.kr/p...
['죽음의 블루스크린' 주범 크라우드 스트라이크 CEO, 美 하원 청문회 소환]
www.chosun.com...
오늘도 잘 듣고 갑니다~~
최소한 IT기사 쓰시는 분들은 기술을 알아보고 적을 필요가 있는것 같습니다.
언론사도 장사를 해야 돈을 벌 것이니... 이해 하고자 합니다. 의견 고맙습니다. :)
전봇대에 꼬인 전선처럼 서로 연계되는 부분이 너무많아서 함부로 할 수도 없는 현실.....
적절한 비유라 생각합니다. 손도 대기 싫은 경우가 너무 많지요...ㅠㅠ
이거 안올려주시나 했는데 역시나 올려주셨군요. 잘 보겠습니다~
기대에 부응한 것 같아 다행이네요. :)
와 이거 커뮤니티 댓글에 해주먄 좋겠다고 했는데 바로 올라오시는군요!! 하하
썰 풀어주실 때 너무 재밌어요!
좋게 봐주셔서 고맙습니다. :)
선생님, 항상 흥미로운 영상 감사합니다!! 일 끝나고 맥주 한잔 마시면서 보면 힐링이 됩니다:)
이 사건에 대해 제 의견도 남기고자 합니다.
보편적으로 발생한 문제 = 일반적인 테스트를 시행했다면 쉽게 발견되었을 문제, 라고 생각합니다. 그렇다면 정상적인 테스트 없이 해당 패치를 배포했을 가능성이 높아 보입니다. 만약 실제로도 그렇다면, 크라우드 스트라이크사의 담당 엔지니어는 도대체 무슨 악과 깡으로 테스트 없이 배포할 생각을 했을까요?!
마이크로소프트사는 많이 억울하겠네요. 괜히 엮여서 고생입니다.
제가 일하던 전 직장은 해외의 유명한 금융회사 였는데, 이곳은 극히 예외적인 경우를 제외하면 절대로 테스트 없이 소프트웨어 변경을 하지 않습니다. 또한 테스트가 끝난 경우에도 절대로 동시에 적용하지는 않으며, 무언가 잘못될 경우 대체하여 투입 할 수 있는 리소스 및 시스템은 항상 준비하여 둡니다. 분산 투자와 마찬가지 이유로요.
델타 항공 이야기가 나왔는데 이 부분은 다른 업계, 다른 회사에서도 진지하게 고려 해 볼 부분이라 생각합니다. 또한 저는 클라우드 100% 의존은 몹시 위험한 발상으로 보고 있습니다.
그리고 이런류의 IT사건은 의외로 흔하다면 흔하지요. 미국 나이트 캐피탈, 한국 한맥 증권 사건을 살펴보는 것도 재미있을 것 같습니다. 비교적 최근에는 도쿄 증권 거래소가 잘못된 IT 인프라 교체로 인해 크게 사고를 친 적도 있지요.
술 한잔 했더니 말이 길어졌습니다. 기회가 되면 리스크 관리에 대해 이야기 해 보고 싶네요ㅎㅎ
제 생각은 조금 다릅니다. 테스트 절차를 시행하지 않았다기 보다 엉뚱한 파일을 배포하는 실수를 했다거나 자신들이 구축한 테스트 환경을 벗어났을 수 있습니다. 개인적으로는 전자 가능성이 높지 않나 추측해봅니다. 직원의 사소한 실수 하나로 조직이 무너지는 경우는 종종 있으니까요.
사실 중요한 것은 왜 재해대책 시스템이 전혀 작동하지 않았는가 입니다. 그 문제는 아예 논의 조차 하지 않는 것으로 보이는데...이 역시 이해할 수 없는 부분입니다. 의견 고맙습니다. :)
@@nullnull_not_eq_null
아! 선생님 말씀을 듣고보니 “엉뚱한 파일을 배포하는 실수”의 가능성이 높아보이네요!!
오래전 읽은 사례라 정확한 기억은 아닐 수 있습니다만, 예시로 든 미국 나이트 캐피탈 사건이 그와 비슷한 사례였다고 합니다.
해당 사례는
1) 직원의 조작 실수로 잘못된 패치를 적용
2) (고빈도 트레이딩 시스템이기 때문에) 사람이 대응 하기에는 이미 늦음
3) 순식간에 도산
이었던 것으로 기억합니다.
금융권 IT리스크도 무섭지요. 이런 부분을 감정적으로 감당할 수 있는 사람이 많지 않기 때문에 월급이 높은 것일지도 모르겠습니다.
설명을 재대로 하는 기사를 찾기 어려웠는데, 잘 설명해주셔서 감사합니다.
좋게 봐주셔서 고맙습니다. :)
다른 정보봤더니 컴퓨터가 무한 리부팅이되서 컴퓨터에 직접 키보드 연결해서 safe boot 한다음 config 파일을 지워줘야 됬다고 하는데 조치가 필요해 보이네요 ㄷㄷ
되서->돼서
커널 드라이버 오류가 발생하면 블루스크린이 떠버리기 때문이지 싶습니다. :)
@@user-vf1tj3vg6s ㅈㅅ합니다.. 외국살다와서..
업계에서 잔뼈가 굵은 고수의 향기가 아주 진하게 묻어나오는 설명 잘 듣고 바로 구독 박고 갑니다 알찬 영상 감사합니다!
좋게 봐주셔서 고맙습니다. 앞으로도 열심히 영상 올리겠습니다. :)
IT관점에서의 기사 설명. 감사히 잘 봤습니다.
좋게 봐주셔서 고맙습니다. :)
오늘도 영상 감사드립니다~
제가 더 고맙습니다. :)
웹개발자여서 요런 생각을 하는 것일지 모르지만욤
이런 종류의 제품은 카나리 배포처럼 5% -> 50% ->100% 이런식으로 적용범위를 조금씩올리는 배포는 힘들까요?
배포과정이 어떻게 될까 단순 궁금증이 생기긴 합니다.
기본지식없이 상상해본 배포과정으로! yum repository에 새로운 버전을 등록하는 순간 전체적으로 적용이 되기때문에 방법이 없는걸까? 생각도 드네요(자신감없음...)
커널 모듈은 그게 불가능 합니다. 그리고 그 배포라는 것이 윈도우 업데이트와 비슷한 성격이라 보시면 되겠습니다. 참고하시기 바랍니다. :)
영상 감사합니다
좋게 봐주셔서 고맙습니다. :)
정말 궁금했던 사안인데 감사합니다
그러셨군요. 마침 요청이 있어서 올리긴 했는데... 적절했던 것 같네요. 고맙습니다. :)
부탁드렸던 영상 감사합니다!
답변이 됐으리라 기대해봅니다. :)
궁금했는데, 내용 올려주셔서 감사합니다!
예전에 알약 랜썸웨어 BSOD도 드라이버 충돌로 인한 비슷한 문제였던 것 같네요
드라이버 충돌을 기술적으로는 API Hooking 중복으로 인한 문제로 이해하면 맞을까요??
혹시 가능하다면, AV NGAV EPP EDR에 대한 차이를 알려 주실 수 있으실까요?
여러 자료들을 보아도 이 차이가 명확하게 이해가 되질 않아서요 ㅠ
네, 맞습니다. 드라이버 충돌은 늘 심각한 문제로 이어지지요. 그리고 그 원인이 항상 API hook 때문만은 아닙니다. 물론 다수의 원인이 되기는 하지요. 참고하시기 바랍니다. :)
참, 용어에 대한 해설은...고려해보겠습니다.
써드파티 앱 잘못이라 ms가 좀 억울한 면이 있긴 하지만 그 여파로 치면 전대미문의 사건은 맞습니다.
그런 대비가 안되어있다는 점에서는 ms 도 자유로울 수 없죠. 자동으로 부팅 성공한 마지막 버전으로 돌리던지 방법이 아주 없진 않았을거 같구요.
해외뉴스도 원인을 잘 모른채로 ms 탓을 하거나 해당업체 지사에서 대응미숙 탓을 하기도 했답니다. 어쩔 수 없다고 생각합니다
그 대비의 기준이 참 애매한 측면이 있습니다. 어쨌든 재해대책 시스템이 정상적으로 가동되지 않은 것은 분명해 보입니다. 그 관점에서 책임을 논하는 것이 적절하겠다는 생각을 해봅니다. 좋은 의견 고맙습니다. :)
오늘의 결론 엔드포인트 보안은 인간이 할 것이 아니다
네, 저는 포기했습니다. ㅠㅠ
그날 저희회사 엔지니어분들도 몇백대 서버를 일일히 조치하느라 고생하셨죠....
인공지능 시대가 오더라도...이런 문제는 대응하기가 참 쉽지 않을 것 같습니다. :)
와... 제목만 보고 ms 장애인줄 알았는데
보안업체 문제였구만
네, 우리나라에서도 몇 번 있었던 일이지요. ㅡㅡ
널널한 = 커널이죠 ;; ㅋㅋㅋㅋㅋ
이야기가 그렇게 되는 군요. 피드백 고맙습니다. :)
물론 윈도라서 무조건 문제고, 유닉스 계열이라서 무조건 괜찮다 라는건 아니지만, 그래도 왜 윈도우를 서버로 쓰는지 아직도 모르겠네요...
지속적으로 블루 스크린이 떠도, 지속적으로 사용하는 그 아집과 용기는 어디서 나오는지..
말씀하시는 바는 저도 충분히 이해합니다만... 기업의 입장에서 생각 해 볼 수 있는 논점도 말씀드리고자 합니다.
이러한 사건은 윈도우 문제가 아니라 윈도우 어플의 문제가 아니겠습니까? 유닉스 계 OS에도 잘못된 어플에 의한 사고의 위험은 있으며, 윈도우 어플에 의한 사고 리스크는 다른 방식으로도 관리가 가능합니다.
또한 기존 소프트웨어와의 호환성, 엔지니어 채용 및 교육에 드는 비용, 윈도우를 전제로 개발된 편리한 라이브러리들이 윈도우의 이점이 되는 경우도 많습니다.
물론 (적어도 제가 아는 한) 리눅스 등 다른 OS에의 이행도 당연히 진지하게 검토합니다. 실제로 기간 시스템을 리눅스로 이행하는 경우도 보았습니다.
다만 기업의 경영 환경을 고려했을때, 윈도우가 선택되는 비율이 높은것은 사실입니다. OS선택에 수반되는 전체 비용 및 리스크를 따져보면 윈도우가 꽤 괜찮은 선택지거든요.
Windows Server 자체는 굉장히 좋은 os예요. 기업들에서 서드파티 솔루션을 엄청나게 설치하면서 성능 저하와 문제가 생기는거지…
Windows Server를 쓰는 이유는 유닉스랑은 다르게 엔터프라이즈급 백오피스 생태계가 압도적으로 좋아서 그렇습니다.
@@testchannel8451
2000년대 초반 부터 리눅스 서버를 봤고, 국내서 본격적으로 사용된지 15년도 넘은거 같은데
윈도우 쓰는 쪽에서 하시는 이야기는 15년전이나 지금이나 똑같은 이야기네요.(이래서 안되고 저래서 안되고..) -> 블루스크린 계속 순환
@@user-bm6us5xu9n
나름대로 정중히 윈도우를 선택히는 기업측 입장도 설명드리고자 했는데, 제가 생각하는 예의의 기준이 지나치게 높은 것일까요?
아니면 윈도우에 상당히 불만이 많으신가 봅니다ㅎㅎ 극단적인 사고방식은 좋지 않습니다.
@@testchannel8451
ㅎ 기분 나쁘셨다면 죄송 합니다.
제가 이야기 하는 것은 윈도우는 서버로서 블루스크린이라는 치명적인 단점이 있다는 겁니다. 이게 써드파트 어플 문제니 뭐니 이렇게 이야기 하지만, 그게 과연 써드파트 어플만의 문제일까요?
대부분은 그렇게 말합니다. 잘만들면 된다..
과연 쉬울까요?