Какие функции системного администратора должны знать каждый программист?

Как программист, мы склонны воспринимать системных администраторов как должное. Несколько раз, когда я был без хорошего сисадмина, я действительно оценил то, что вы, ребята, делаете. Когда мы отправляемся в среду без системного администратора, какие слова мудрости вы можете нам предложить?

96 голосов | спросил 6 revs, 4 users 100%
Nathan DeWitt
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

18 ответов


70

Я бы начал с:

  1. Всегда имеют резервную систему. Еще лучше, если у него есть история.
  2. Рассмотрите отдельные точки отказа и как с ними справиться, если они потерпят неудачу.
  3. В зависимости от количества задействованных компьютеров поиск определенного способа создания и создания стандартного образа на компьютерах облегчит жизнь каждого человека - нет «он работает на моем», потому что у них есть такая-то программа, которая обычно не установлена.
  4. Документируйте все, хотя бы потому, что вы забыли, как вы что-то установили.
  5. Следите за обновлениями безопасности.
ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
44

<insert большой отказ от ответственности здесь>

Некоторые из них были упомянуты раньше, но это стоит повторить.

Документация:

  • Документируйте все. Если у вас его нет, установите под-радарную вики, но убедитесь, что вы его поддерживаете. Начните с сбора фактов, и однажды появится большая картина.

  • Создайте диаграммы для каждого логического блока и сохраните их. Я не мог подсчитать количество раз, когда была сохранена точная карта сети или диаграмма кластеров.

  • Храните журналы сборки для каждой системы, даже если это просто скопировать и вставить команды для ее создания.

  • При создании вашей системы установите и настройте свои приложения, протестируйте ее и выполните бенчмаркинг. Теперь вытрите диски. Шутки в сторону. 'dd' первый мегабайт с передней части дисков или иначе сделать коробку не загружаемой. Часы тикают: докажите, что ваша документация может перестроить его с нуля (или, что еще лучше, доказать, что ваш коллега может ничего больше, чем ваша документация). Это будет составлять половину вашего плана аварийного восстановления.

  • Теперь у вас есть первая половина вашего плана аварийного восстановления, запишите остальные; как восстановить состояние вашего приложения (восстановить файлы с ленты, перезагрузить базы данных из дампов), сведения о поставщике /поддержке, требования к сети, как и где получить заменяющее оборудование - все, что вы можете придумать, поможет восстановить вашу систему.

Автоматизация:

  • Автоматизируйте как можно больше. Если вам нужно сделать что-то три раза, убедитесь, что второе потрачено на разработку вашей автоматизации, поэтому третий полностью автоматизирован. Если вы не можете автоматизировать его, запишите его. Там есть комплекты автоматизации - посмотрите, можете ли вы заставить их работать для вас.

Мониторинг:

  • Прикладная аппаратура - это чистое золото. Возможность просматривать транзакции, проходящие через систему, значительно облегчает отладку и устранение неполадок.

  • Создавайте сквозные тесты, которые доказывают не только то, что приложение живое, но и действительно делает то, что он должен. Очки зачисляются, если их можно подключить к системе мониторинга для целей оповещения. Это служит двойной обязанности; помимо проверки работы приложения, он значительно упрощает обновление системы (мониторинг системных отчетов зеленый, обновление, время, чтобы вернуться домой).

  • Контролируйте, контролируйте и собирайте показатели на все, что подходит для этого. Тесты говорят вам, когда ожидать, что что-то выпустит волшебный дым. Мониторинг сообщает вам, когда он есть. Метрики и статистика облегчают получение нового набора (со свежим магическим дымом) через управление.

  • Если у вас нет системы мониторинга, выполните ее. Бонусные баллы, если вы действительно используете эти сквозные тесты.

Безопасность:

  • «chmod 777» (также предоставляющий все права доступа /привилегии) ​​никогда не является решением.

  • Подпишитесь на принцип «наименьших бит»; если он не установлен, не скопирован или не живет на диске, он не может быть скомпрометирован. Установка «кухонной раковины» и установка программного обеспечения могут облегчить жизнь на этапе сборки, но вы в конечном итоге платите за нее по трассе.

  • Знайте, для чего нужен каждый открытый порт на сервере. Регулярно проверяйте их, чтобы не появляться новые.

  • Не пытайтесь очистить взломанный сервер; его нужно перестроить с нуля. Перестройте на резервный сервер со свеже загруженным носителем, восстановив только данные из резервных копий (поскольку могут быть скомпрометированы двоичные файлы) или клонируйте скомпрометированный хост где-то изолированным для анализа, чтобы вы могли перестроить его в том же комплекте. Во всем этом есть целый законный кошмар, так что ошибайтесь на стороне сохранения, если вам нужно заниматься юридическими средствами. (Примечание: IANAL).

Оборудование:

  • Никогда не предполагайте, что что-то будет делать то, что он говорит на коробке. Докажите, что он делает то, что вам нужно, на всякий случай, если это не так. Вы обнаружите, что говорите «он почти работает» чаще, чем выожидать.

  • Не экономьте дистанционное управление аппаратным обеспечением. Последовательные консоли и управление огнями следует считать обязательными. Бонусные очки для дистанционно управляемых силовых полос для тех случаев, когда у вас нет параметров.

(Помимо этого: в 3 часа есть проблема с двумя проблемами: одна - тепло, работая на ноутбуке через VPN в вашей пижаме, другая - толстая куртка и привод в центр обработки данных /офис. который я предпочитаю.)

Управление проектами:

  • Привлечь людей, которые будут поддерживать систему с первого дня жизненного цикла проекта. Время выполнения на наборе и времени в мозге может и будет удивлять, и нет сомнений, что они будут (должны?) Иметь стандарты или требования, которые станут зависимыми от проекта.

  • Документация является частью проекта. Вы никогда не получите время, чтобы написать все это после того, как проект был закрыт, и система перешла на обслуживание, поэтому убедитесь, что он включен в качестве усилия по расписанию в начале.

  • Внесите запланированное устаревание в проект с первого дня и запустите цикл обновления за шесть месяцев до выключения, указанного в проектной документации.

Серверы имеют определенный срок службы, когда они подходят для использования в производстве. Конец этой жизни обычно определяется как всякий раз, когда продавец начинает взимать больше в ежегодном обслуживании, чем это потребуется для обновления набора, или около трех лет, в зависимости от того, что меньше. По прошествии этого времени они отлично подходят для сред разработки /тестирования, но вы не должны полагаться на них, чтобы управлять бизнесом. Пересмотр среды на 2 1/2 года дает вам много времени, чтобы перепрыгнуть через необходимые управленческие и финансовые обручи для заказа нового набора и провести плавную миграцию, прежде чем отправлять старый комплект крупному вендору в небе.

Разработка:

  • Убедитесь, что ваши системы разработки и постановки напоминают производство. Технологии VM или другие методы виртуализации (зоны, LDOM, vservers) облегчают создание клонов реального мира в каждом смысле, но производительность.

Резервные копии

  • Данные, которые вы не создаете резервную копию, - это данные, которые вы не хотите. Это непреложный закон. Убедитесь, что ваша реальность соответствует этому.

  • Резервные копии сложнее, чем они выглядят; некоторые файлы будут открытыми или заблокированными, тогда как другие должны быть готовы к тому, чтобы иметь какую-либо надежду на восстановление, и все эти проблемы необходимо решить. В некоторых пакетах резервного копирования есть агенты или другие методы обработки открытых /заблокированных файлов, а другие пакеты - нет. Сбрасывая базы данных на диск и поддерживая их, считается одной из форм «quiescing», но это не единственный метод.

  • Резервные копии бесполезны, если они не протестированы. Каждые несколько месяцев извлекайте случайную ленту из архивов, убедитесь, что на ней действительно есть данные, и данные согласованы.

И самое главное ...

Выберите свои режимы сбоев, или Мерфи будет ... и Мерфи не будет работать по вашему графику.

Дизайн для отказа, документируйте слабые стороны каждой системы, что их запускает и как восстановить. Все будет иметь значение, если что-то пойдет не так.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
43

Не считайте его легким. Я знаю много программистов, которые думают, что только потому, что они могут настроить IIS или Apache, там dev, чтобы они могли запускать веб-ферму. Поймите, что включает в себя работа и выполняете ваши исследования и планирование, не просто думайте, что работа с системным администратором - это легкая вещь, которую вы можете сделать за 10 минут, чтобы развернуть свое приложение.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
27
  • Поймите, что к лучшему или худшему многие серверы и /или сетевое оборудование, как правило, очень похожи на детей из второй семьи. Это их дети. Они склонны к ним, помогают им, когда они болят, и внимательно следят за ними. Это не должно быть таким образом, но через много лет это часто . Помните об этом, когда вы сообщаете им о своих проблемах, связанных с неправильным функционированием оборудования или ожиданием. И если вы получите ответ, который вы не понимаете, попробуйте фильтровать его в этом мире.
  • Будьте на хороших рабочих условиях. Звучит сыро, но это стоит своего веса в золоте. Когда-нибудь вам понадобится особая услуга. И однажды, этот системный администратор будет рад выйти из своего пути, чтобы сделать жизнь немного легче для вас, только в этот раз.
  • Эти рабочие отношения идут в обоих направлениях. Если sysadmin очень занят, и вы можете сделать жизнь немного легче, написав небольшой скрипт или программу, тогда сделайте это! Они оценят это больше, чем вы знаете.
  • Будьте предельно ясны. «Это отстой» не так ясно, как «наличие прерывистого сетевого соединения немного раздражает, любой шанс вы можете посмотреть на него?»
  • Если вы считаете, что ваше приложение будет масштабироваться, спросите администратора до при условии . Они могут «видеть» то, что у вас нет, или знать что-то о пределе производительности оборудования, которое вы собираетесь развернуть.
  • Если ваше приложение нуждается в настройке, но оно не является проблемой кода, спросите о том, как работают серверы. Сисадмины с любовью заботятся о своих машинах и не радуются, когда они «болят» или «плохо себя ведут». С удовольствием попробуем обратиться к больной машине (или получить ее починить /заменить).
  • (как упоминалось в другом месте) документируйте используемые вами настройки и why , которые вы используете. Простое «установить checkbox X» или «uncomment config file line Y» не помогает. Вы можете установить параметр, который удаляет все ваши данные при следующей перезагрузке для всех, кого вы знаете.
  • Если у вас нет времени для документирования настроек на бумаге, попробуйте записать его в систему, если это возможно. В конфигурационных файлах это должно быть практически стандартным - каждое изменение настроек должно быть датировано, с инициалами, ожидаемым эффектом этого параметра и причиной почему он был изменен (см. Предыдущую маркерную точку). Эта маленькая привычка спасла мой бекон не один раз во время хруста. «Почему мы это сделали?» «Потому что мы назначили политику X, а настройка Y дает нам поведение, которое нам необходимо для политики X».
  • Пиво. Или Кола. Или даже вода. Напитки всегда приветствуются. Быть сисадмином - это жаждущая работа.
ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
23

Безопасность не является запоздалой. В то время как взломанное приложение может заставить программиста выглядеть некомпетентным, это (по крайней мере) потерянный уик-энд провел проверку, очистку и /или восстановление из резервных копий для sysadmin.

В этом случае не рассматривайте резервные копии как средство контроля версий. Они предназначены для аварийного восстановления и не предназначены для восстановления кода, потому что вы забыли, что изменили.

И прекратите слепо обвинять Windows Updates в том, что ваш код сломан. Мне все равно, что это сработало, скажите, почему это не работает сейчас - тогда мы можем видеть, чья это вина.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
17

Как отладить сетевые проблемы и посмотреть, как ваша программа запускается с помощью инструментов sysadmin. Как программист, который начал работать в системном администрировании, я поражен тем, как бессильно многие программисты становятся когда-то сетевыми «просто останавливаются».

  • Wireshark , чтобы посмотреть, как ваш код запускается в режиме черного ящика, пакет за пакетом
  • Инструменты для прямого подключения к сетевым службам:
    • Telnet, netcat или socat для простых соединений через TCP или UDP
    • OpenSSL для одного и того же с шифрованием (подсказка: попробуйте openssl s_client -connect target-host:port когда-то), для ручного подключения к сетевым службам
  • dig (в пакете BIND 9) для отладки разрешения имен
  • Возможность рассказать, какая часть сетевого стека была неудачной на основе времени и других характеристик отказавшего соединения.
  • Возможно HTTPFox и /или Firebug
ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
14

Знайте, как устранить проблемы.

Очень легко передать доллар (например, ваша сеть связывает мое сообщение с базой данных). Это может быть ошибка сети, но у вас должны быть журналы приложений с ошибками, которые с помощью Google или SO могут выявить проблему в конфигурации приложения.

Всем нравится обвинять аппаратное обеспечение, ОС или сеть, поэтому, если вы немного попрактиковаетесь, вы сделаете системного администратора счастливым человеком. Потому что, если ничего другого, вы можете указать им в определенном направлении относительно того, что может быть неправильным (в отличие от того, чтобы сказать «ваша сеть сосет» или что-то в равной степени полезно).

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
8

Документируйте все, что сможете. Не могу сказать, сколько раз последний системный администратор думал, что было бы мило, чтобы не документировать что-то для «безопасности работы», или кто-то просто хотел войти и выйти. Так же, как программист должен оставлять хорошие комментарии, системные администраторы должны документировать. Диаграмма топологии тоже будет приятной.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
7

План B.

При разработке и разработке решения всегда учитывайте план аварийного восстановления. Признайте отдельные точки отказа, которые могут привести к отключению.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
6

Документация: не нужно гайки, но как работает приложение, диаграмма, показывающая, как подходят биты, и способы тестирования каждого компонента, когда все идет не так. Примеры данных и вывода хороши.

Требования: на каких модулях он основан? Версии? OS?

Мониторинг: в идеале разработчики будут включать в себя информацию мониторинга и тесты с приложением.

Говоря об упаковке, УПАКОВКА! Ничего хуже, чем «развертывание», что означает проверку новой редакции файла из VCS и копирование его на кучу серверов. Слишком часто программисты не понимают сложность развертывания программного обеспечения: есть причины, по которым версия, упакованное программное обеспечение образует основу большинства ОС.

Если разработчик пришел ко мне с RPM, который установил первый раз с краткой, всесторонней документацией и некоторыми испытаниями Nagios, они были бы моим новым лучшим другом.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
6

Я удивлен, что не из 17 ответов, приведенных здесь до сих пор, включает в себя что-нибудь об обеспечении запуска вашего приложения при входе в систему как стандартного пользователя.

Помимо процесса установки, приложение должно работать нормально при входе в систему со стандартной учетной записью пользователя.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
4

Резервное копирование резервного копирования .... Протестируйте резервную копию ... Всегда будьте готовы к откату

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
4

Это может относиться только к начинающим программистам, но я имею дело с несколькими вещами в каждом проекте с некоторыми программистами.

  1. «Он работает на моей машине», никогда не является действительным заявлением. Ответственность программиста заключается в создании программы установки для использования на сервере или, по крайней мере, документировании каждого соединения и dll и надстроек, которые потребуются на сервере.

  2. (Я слышал это несколько раз, поэтому, пожалуйста, не смейтесь) Я запускаю exe на сервере с моей машины, и это работает. Но когда я запускаю его на сервере (Citrix, Terminal Server и т. Д.), Он не работает. Пожалуйста, поймите, что у dll и ocx есть все, что требуется вашей программе, и где и как они зарегистрированы, и как ваша программа использует их.

Это может показаться простым, но я постоянно общаюсь с ним.

Брайан

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
4
  • поговорите с администратором как формально, так и неофициально о том, что вы делаете. Они, как правило, будут заинтересованы и могут выражать возможные последствия для производства на раннем этапе. Вы не должны соглашаться, но это помогает выявить проблемы.
  • Нет, вы не можете иметь весь сервер для себя ... Если вам это нужно, это политическое решение, независимо от того, насколько это технически здорово. Если вы хотите работать в политике, идите прямо вперед.
  • Производственное оборудование часто выглядит иначе, чем ваш сервер разработки и даже внутри ферм, спецификации на машинах отличаются.
  • Узнайте, как настроено производство, потому что вы, вероятно, не можете его реплицировать на свой рабочий стол, поэтому это мешает вам делать плохие предположения.
  • Просто потому, что вы можете кэшировать материал в памяти, это не значит, что вы должны, прежде всего, ждать узкого места (в модульном тестировании или тестировании производительности перед производством).
  • Если вы вставляете данные в базу данных, подумайте о том, как вы можете разбить данные на данные только для чтения (которые могут быть масштабированы по горизонтали) и данные для чтения и записи (которые обычно только вертикально масштабируются).
  • Если вы вставляете данные в базу данных, должно быть, действительно быть РСУБД? есть другие системы пары ключей и значений, которые лучше масштабируются (неткач).
  • Не думаю, что AJAX - это решение для всех, оно выглядит круто, но ограничивает возможности мониторинга и автоматизации. Я не говорю, что не использую его, просто подумайте дважды.
ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
4

ОК, это немного разглагольствует, но:

a) При кодировании предположите, что базовая инфраструктура может потерпеть неудачу и не исходит из счастливой жизни всегда на земле. Или Google.

b) У нас, вероятно, нет ресурсов для реализации чего-либо подобного инфраструктуре, о которой вы читали, так что успокойтесь, когда ситуация упадет. Скорее всего, мы знаем, что нужно делать, но по какой-то причине этого еще не произошло. Мы ваши партнеры!

c) Как и jhs, упомянутое выше, это действительно помогло бы, если бы вы знакомы с инструментами для устранения неполадок инфраструктуры, таких как ping, traceroute (или комбинирование обоих - mtr), выкапывание и т. д. Массивные бонусные баллы за то, что они даже знали о Wireshark.

d) Если вы программируете компьютер, вы действительно должны знать, как он подключается к сети, и основы, такие как возможность синтаксического анализа вывода ipconfig /all или ifconfig. Вы должны иметь возможность подключиться к Интернету с минимальной помощью.

В противном случае я думаю, что Эйвери довольно много прибил его. Devs, которые делают маленький sysadmin, стоят своего веса в золоте! Но в равной степени, системные администраторы, которые понимают, как разработчики делятся на вещи (включая управление версиями и т. Д.), В наши дни очень важны.

Кажется, что в настоящий момент в воздухе, я заметил больше обсуждений об отношениях dev /ops в блогах - проверьте

Сохранение Twitter Twitter

Разделы и войны

Тест сначала в операциях

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
3

То, что ни одна группа или функция не «лучше», чем другая, и что ни один из них не требует «большего мозга», чем один другой. Я видел, как обе стороны получают все prima-dona'ish в другой компании - вы все пытаетесь достичь одних и тех же целей - сосредоточьтесь на этих сходствах, а не на том, что вы используете разные инструменты.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
2

Архитектор инфраструктуры превратил программиста, возможно, захочет отменить эту транзакцию в будущем:)

  1. Разговаривайте друг с другом, рано и часто. Просмотрите проекты с парнями, которые будут управлять инфраструктурой, на которую ваше приложение будет развернуто (если вы знаете, кто это будет).
  2. Возможна потеря нулевой информации, но это ответственность, которую разделяют разработчики и системные администраторы. Опять же, разговоры друг с другом могут помочь здесь.
  3. Ваш персонал инфраструктуры должен был принять участие в определении нефункциональных требований.
  4. Организуйте пиво (когда работа будет выполнена) и пицца (пока мы работаем). Каким-то образом присутствие такого рода продуктов влияет на нашу способность делать наши красивые маленькие 32-процессорные коробки, что бы вы им ни делали:)
ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53
2

Как кто-то, кто был администратором sys для разработчиков и сам разработчик, приведенный здесь совет - это не только золото, но и должно быть частью документации по найму для новых разработчиков для компаний по всему миру.

Что-то, что я еще не видел (пока), объясняется тем, что разработчики действительно должны знать продукты, которые они будут использовать для создания программ, за которые им платят. Количество раз, которое я должен был объяснить и настроить серверы apache, установки eclipse и Visual Studio и базу данных на машинах для разработчиков, вызывает некоторую тревогу.

ответил San 28 Jam1000000amFri, 28 Jan 2011 01:49:53 +030011 2011, 01:49:53

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132