답변:
응용 프로그램의 작동 상태가 작동 중지 또는 중지보다 많을 수 있습니다. 상태 다이어그램을 그립니다. 대부분의 응용 프로그램에는 다음과 같은 상태가 있습니다.
각 상태에서 시스템이 충돌하면 어떻게되는지 생각해보십시오. sysadmin은 상태 전환을 어떻게 모니터링하고 제어합니까?
SA에서 "사용자"를 구별하십시오.
"사용자"는 소프트웨어 사용법을 알아야합니다. 사용자는 소프트웨어 설치 방법과 같은 것을 신경 쓰지 않습니다.
SA는 소프트웨어 사용 방법을 신경 쓰지 않지만 소프트웨어 설치 방법에 대한 중요한 세부 정보를 알아야합니다.
각 역할과 관련된 정보를 포함하여 각 역할별로 문서를 별도로 작성하십시오.
내 소원 중 하나는 예외 및 오류 코드에 적절한 메시지를 포함시키는 것입니다. 응용 프로그램을 개발하지 않은 사람에게는 완전히 불투명합니다 JimmyNotAtHomeException: it's late!.
그러나와 같은 메시지 Unable to find jimmy - initial manual call_mother procedure는 매우 도움이됩니다.
커뮤니케이션, 커뮤니케이션, 커뮤니케이션. sysadmin과 개발자 사이의 모든 문제는 항상 통신 부족으로 추적 할 수 있습니다. 프로젝트 이전에 시스템 관리자 (또는 그 대표자)와 개발자들이 모여 훌륭한 프레임 워크 토론을했다면 SOOOOOOOOOO 많은 문제를 피할 수있었습니다. 응용 프로그램이 App 서버 + DB 서버 + 인터페이스 서버 등으로 분리되어 있기 때문에 개발중인 하나의 상자에있는 모든 사람을 개발하여 화염에 빠지는 것을보기 때문에 얼마나 많은 것들이 파울 링되는지 말할 수 없습니다. 이 주제를 제기 해 주셔서 감사합니다.
프로젝트 초기에 참여하십시오. 기능적 사양 단계에서 실제와 같이 초기에.
다른 사람은 모든 PC에 수동으로 설치해야한다고 언급했지만 구성 및 구성 변경에도 동일하게 적용됩니다. 클라이언트 쪽의 연결 문자열과 같은 것을 저장하기로 선택하고 정기적으로 업데이트 해야하는 경우 아마도 당신을 죽이고 싶을 것입니다 .
같은 이유로 중앙에서 적절하게 관리 및 구성 할 수있는 기술을 선택하십시오. 우리가 사용하는 모든 중앙 관리 도구와 잘 통합되는지 확인하십시오.
항상 최저 공통 분모를 사용하여 테스트하십시오. 이는 가장 원시적 인 OS, 응용 프로그램 제품군 및 브라우저 플랫폼에서 일반적으로 사용되는 비 관리자입니다. 우리는 마지막 순간에 모든 사용자에게 필요한 브라우저 업그레이드가 마음에 들지 않습니다.
일이 잘못 될 때 우리를 탓하지 마십시오. 예전에는 앱이 깨질 때마다 개발자가 즉시 손가락을 가리킬 것입니다. "새 패치를 설치했는데 브라우저를 업그레이드하지 않으며 보안이 너무 엄격합니다." 이것은 파괴적인 분위기를 생성합니다. 우리는 실제로 같은 편이며 문제를 해결하기 위해 당신과 함께 일하고 싶지만 그러한 상황에서는 할 수 없습니다.
엘리트가되지 마십시오.
"내 시간을 허비하지 말아라. 당신은 단지 dogsbody sysadmin 일 뿐이다 . 나는 소프트웨어를 작성하고 당신은 단지 그것을 서비스한다. 그래서 당신의 사소한 문제를 해결하고 내가 말한대로하라."
개발자는 실제로 그 말을 한 번만 말했습니다 (1). 이메일로. 대규모 메일 그룹에 참조되었습니다. 그 의미는 분명하다. 개발자로서 그는 전체 소프트웨어 세계의 주인이자 주인이었다. 그리고 나는 그에게 귀중한 시간을 낭비하기에 너무 사소한 일을 처리하기 위해 단순히 일꾼으로 고용되었습니다. 물론 이것은 거의 최악의 예이지만, 이전과 이후의 많은 개발자들로부터 그 의견에 대한 강하고 약한 반향을 들었습니다 (2).
당신은 나보다 더 많은 돈을 벌 수 있습니다 (그러나 그것을 가정하지 마십시오!). 그러나 사용자가 사용하는 시스템을 구축, 운영 및 유지 관리하려면 팀이 필요합니다. 궁극적으로 우리 모두가 그들을 제공합니다.
나는 당신의 직업과 기술이 나의 것과 다릅니다. 나는 당신의 능력을 존중합니다. 초등하고 어리석은 것처럼 보일지라도 내 질문에 대답하기를 바랍니다. 기쁜 마음으로이 예의를 돌려 드리겠습니다!
많은 나쁜 (또는 단순히 무관심한) 개발자들이 다양한 포럼에서 말하고 생각하고 게시했기 때문에 나는 미친 파워 트립에 있지 않습니다. 그러나 나의 관심사는 당신의 것과 다르며, 나의 질문과 제안은 나의 자존심에 도움이되지 않습니다. 실제로 내 임무는 앱을 최고의 실행 상태로 유지하고 모든 사용자에게 응답하고 사용 가능한 상태로 유지함으로써 더 나은 모습을 만드는 것입니다. 그러기 위해서는 나머지 네트워크와 시스템도 최고 수준으로 유지해야합니다.
나는 당신이 과거에 어리 석고, 힘이 넘치고, 그리고 / 또는 평범한 게으른 관리자를 만났다는 것을 완전히 알고 있습니다. 나는 하나가 아닌 하나처럼 보이려고 노력하고 있습니다. 만약 당신이이 가능성을위한 여지를 남겨두고 당신이 그것을 볼 때 그것을 인정한다면, 나는 당신이 다른 멍청한 놈들이 여전히 그들의 sysadmin이 멍청한 것에 대해 연기하고있는 동안 당신이 필요한 것을 얻을 것이라고 확신합니다.
(1) 또한 자신의 프로그램 (소프트웨어 요구 사항 작성 및 관리 도구)이 설치 및 실행을 위해 도메인 관리자 권한이 필요하다고 주장했습니다. 그것은이었다 주요 보안 위험.
(2) 필요할 때 가르치고 필요할 때 배울 수있는 많은 훌륭한 개발자들과도 일했습니다.
시스템 관리자가해야 할 일이 있는지 확인하고 업무를 수행하도록하십시오. 많은 회사들이 무능한 시스템 관리자를 가지고 있으며 이것은 종종 현실적이지 않습니다. 그러나 오만한 개발자는 시스템 관리자가 자신의 역량을 입증 한 후에도 시스템 그룹의 조언을 무시하는 것을 보았습니다.
sysadmins를 사용하여 새 시스템 설계에 대해 논의하십시오. 종종 귀중한 통찰력이 있습니다. 개발자는 종종 sysadmins와의 토론을보고 초기 요구 사항을 "조기 최적화"라고합니다. 실제로 개발 그룹 책임자는 쓰기 집중적 또는 읽기 집중적 부하인지 여부를 설명하는 정도까지 sysadmins 및 DBA가있는 새로운 데이터베이스 서버의 요구 사항에 대해 논의하는 데 시간이 낭비되었다고 말합니다. 필요한 스토리지 용량
sysadmins의 성능 문제에 대해 논의하십시오. 솔직히 시스템 관리자 만이 시스템의 성능 메트릭을 올바르게 해석 할 수 있습니다. 필자는 개발자가 "free"로보고 된 사용 가능한 메모리가 10 번째 시간이 지난 후에도 "free"의 출력이 설명되기 때문에 항상 메모리가 누수된다고 결정하는 것을 보았습니다.
sysadmins와상의하지 않고 결론을 도출하지 마십시오. 개발자들이 "데이터베이스는 항상 디스크에 묶여있다"(iostat가 존재한다는 것을 몰랐 음), "RAID 5가 트랜잭션 워크로드에 더 빠르다"(이동 한 데이터베이스 시스템의 기억에 근거)와 같은 이론에 얽매어있는 것을 보았다. 한 하드웨어 플랫폼에서 다른 하드웨어 플랫폼으로-읽기 집약적 인 워크로드였으며, RAID5 솔루션은 더 많은 컨트롤러에 더 많은 드라이브가 확산되었지만 이러한 세부 사항을 잊어 버렸고 결론 만 기억했습니다.)
sysadmins와상의하지 않고 시스템 문제에 대한 솔루션을 설계하지 마십시오. 개발자가 솔루션을 설계하고 작은 구현 지원을 요구하는 병리학 환경에서 일했습니다. Unix 그룹의 책임자 인 Unix 그룹의 책임자 인 나 자신 외에 Unix 그룹의 구성원은 개발자가 전체 인프라 기능을 만들려는 동료가 아닌 "고객"으로 취급하기를 원했습니다. 고객이 항상 옳다는 것은 그들이 무엇을하고 있었는지 왜 의심하지 않는 것을 의미했습니다. 올바른 해결책을 결정할 수 있도록 설명 된 문제를 주장 할 유일한 사람이었습니다. 이와 같은 병리학적인 환경을 조성하는 방식으로 행동하지 마십시오. 순 이익은 아닙니다. 대신 시스템 관리자가 방어 적으로 행동하고 모든 사람이 고통을 겪게됩니다.
당신은 더 이상 학교에 없습니다. 이들은 실제 시스템이며 이상적인 방식으로 작동하지 않습니다. 예를 들어 모든 것이 대기 시간이없는 것은 아닙니다. sysadmin이 클러스터링 솔루션이 정치적 목적만을위한 것이라고 경고하고 시스템의 추가 복잡성이 전체적인 안정성을 떨어 뜨리면 심각하게 생각하십시오. 실제 장애 모드를 설계해야합니다. 예를 들어 TCP를 통해 통신하는 서버를 잃어 버릴 경우 연결이 재설정되지 않을 수 있습니다. Sysadmin은 실제 장애 모드를 이해합니다.
sysadmin이 말한 내용을 듣거나 sysadmins가 무능하며 해고되어야한다고 경영진에 불만을 제기하십시오. sysadmin을 무시하는 것은 의미가 없습니다.
응용 프로그램 배포 방법을 고려하십시오. sysadmins와이 문제를 논의하는 것이 합리적이라는 것을 인식하십시오. 단일 구성 파일을 기반으로하는 100 개의 서버가 동일하고 중앙 위치에 이러한 구성 파일의 마스터 사본을 저장하는 것이 좋습니다. 응용 프로그램을 쉽게 다시 배포 할 수 있다면 모든 사람이 얼마나 나아질 수 있는지 알아보십시오. 시스템에 문제가있는 경우 1 분 안에 여분의 공간으로 다시 배치하거나 고장난 시스템을 수리하는 동안 몇 년을 기다리시겠습니까? 응용 프로그램을 다시 배포 할 수 있으면 OS를보다 쉽고 안전하게 업그레이드 할 수 있습니다. 앞으로이 문제에 관심이있을 수 있습니다.
OS로 인한 것으로 생각되는 문제가있는 경우 즉시 sysadmin을 호출하여 체크 아웃하는 것이 좋습니다. 그러나 객관적인 조사 결과 아무 것도 드러나지 않으면 문제를 설명 할 의무가 있습니다.
"느리게 응답하는 것과"전혀 응답하지 않는 것 사이에는 차이가 있음을 이해하십시오.
개발중인 OS (en)에 대해 예측 가능한 방식으로 변경하여 예측 가능한 방식으로 구성하고 배치합니다. 이것은 모든 것을 의미합니다. 예를 들어 : OpenLDAP에는 이상한 로그 레벨 방법이 있습니다. 특정 IMAP 서버에는 구성 파일이 없지만 옵션이 컴파일되어 있어야합니다. 어떤 패키지는 그것들이 하나의 특정 디렉토리 경로에 있기를 원하며, 이는 특정 운영 체제의 규칙을 어길 수밖에 없습니다. 이 모든 것들이 내 평소 구성에서 사마귀로 눈에.니다.
그것은 일반적인 규칙이지만, 당신이 특별하다고 가정하지 않으므로 소프트웨어 패키지가 필요한 소프트웨어에 내재 된 충분한 이유가 없다면 소프트웨어 패키지가 일반적으로 플랫폼에서 작동하는 방식에 대한 일반적인 규칙을 어기는 것이 좋습니다. "강력하다고 생각한다"는 것은 모든 사람의 일반적인 설정을 깨뜨리기에 충분하지 않습니다. 소프트웨어가 수행하려는 기능에 연결된 이유 여야합니다.
앱과 관련된 서버 간 통신이있는 경우 설계 단계에서 하나 이상의 sysadmin을 포함 시키십시오. 또한 다른 서비스 (SQL, SMTP, HTTP 등)에 대한 종속성을 명확하게 문서화하십시오. 예상 한대로 작동하지 않을 때 수행 할 작업을 추측하거나 도와 드릴 수 없습니다.
자동화 된 방식으로 수십 또는 수백 개의 시스템에 소프트웨어를 배포 할 수있게하십시오. 조직에 소프트웨어 패키지가 필요한 경우 sysadmins는 모든 상자에 수동으로 소프트웨어를 설치할 시간이 거의 없습니다. 파일에 라이센스 정보가 필요한 경우 파일을 제공하는 방법을 문서화하면 큰 이점이 있습니다.
어도비는 역사적 으로 작업하기가 정말 힘든 일부 설치 프로그램을 가지고있었습니다 . 그보다 더 높은 조준하십시오!
다른 모든 것을 넘어 서면 ...
내 경험상 가장 큰 차이는 개발자가 1 일부터 배포에 대해 생각하는 것입니다. 프로덕션 / 고객 환경에서 새로운 기능을 생각하기 시작하면 그 기능이 어떻게 배포 될지에 대해 생각하기 시작합니다. 환경 및 운영 방법.
일단 개발 프로세스에 들어가면 너무 늦지는 않지만, 시점을 그 시점으로 전환하기까지 시간이 걸릴 수 있습니다. 그들은 코드베이스가 강제로 직면 할 때까지 코드베이스를 얼마나 추상적으로보고 있는지 알지 못합니다. 그들의 마음에, 그것은 단지 "구성 요소"입니다. 이전 버전 (또는 이전 버전)의 소프트웨어를 실행하여 기존 환경에 배포하는 방법이 특히 중요 합니다. 배포 논의는 새로운 기능을 수용하도록 아키텍처를 조정하는 방법에 상당한 영향을 줄 수 있습니다.
지원 가능한지 확인하십시오 : 여기에 언급 된 모든 것 외에도이 게시물을 참조하십시오 -https : //.com/questions/205374/what-are-the-core-elements-to-include-include-support- 선적 서류 비치/