Добрый день. Сегодня поразмышляем на тему того, чем на самом деле занимается системный администратор. Чем он должен заниматься, а чем не должен.
Сисадмины бывают разные.
Какие бывают системные администраторы?
Чем не должен заниматься системный администратор
Но он этим всё равно занимается.
Менять диски и неисправное оборудование
Любое железо выходит из строя. У меня под столом куча дохлого железа, диски, сетевухи, прочая хрень. Сдох диск, его нужно заменить. В работе по замене неисправного диска нет ничего сложного. Да и что там сложного, выдернул дохлый диск, воткнул новый. Должен ли сисадмин менять диски?
Если железо на гарантии, то сисадмин снимает логи, отправляет заявку производителю. Логи могут отправляться производителю автоматически. Производитель высылает инженера, который приезжает и меняет диск. Вы только должны оформить инженеру пропуск в ЦОД. На практике здесь тоже могут возникать сложности. Во-первых, нужно получить информацию об инженере и оформить проход. Есть некоторые объекты, на которые посторонние люди не допускаются, или допускаются в вашем присутствии. Бывает, нужно удалённо светодиодом подсветить сервер или неисправный диск.
У меня был случай, когда инженер от Dell не смог выдвинуть сервер из стойки, поскольку не обнаружил фиксирующих винтов. Пришлось по телефону объяснять что ему нужно делать. Другой инженер от Dell не смог справиться с выдвижной дисковой корзиной, тоже пол часа консультаций.
Техподдержка небезызвестной компании HPE один раз мне заявила, что не занимается заменой дисков, а только более сложного оборудования. Это после того как уже поменяли мне штук пять дисков. Обалдевший я поехал и заменил диск сам.
Иногда приходится менять железо в стойках, оборудованных СКУД. Да, диск меняет техподдержка сервера, но на удалённое открытие-закрытие стойки нужно потратить время.
Однажды неисправный диск привёл к медленной работе RAID контроллера. Сервер стал тормозить, сервисы упали. Пришлось забить на гарантийный ремонт и в спешке ехать в ЦОД с запасным диском.
Есть брэнды (hello Supermicro), на которые гарантия только от продавца. Да, диск заменят, но менять приходится сисадмину, и ждать нового железа пару месяцев.
В любом случае, если есть гарантия, то это уже не плохо. Если есть поддержка, то вообще хорошо. Но гарантия имеет свойство заканчиваться, и здесь уже сисадмину нужно убедить руководство продлить поддержку. И это не всегда удаётся, сервера пашут без гарантии. А если железо не на гарантии, то сисадмину придётся предоставить информацию для закупки нового диска, возможно, приобрести. А потом поехать и заменить.
Если всё обобщить, то не сисадмин должен заниматься заменой дисков, а техническая поддержка серверов. Но участвовать в такой замене всё равно приходится...
Обновлять ПО
Каждый день в программного обеспечении находят ошибки. Безопасники сканируют периметр, находят уязвимости. Чем серьёзнее компания, тем страшнее для неё уязвимое ПО. Вот админы сидят и накатывают обновления. И накатывают обновления. И накатывают, накатывают, накатывают обновления.
А потом откатывают их, потому что что-то сломалось. И времени на откат обычно требуется больше чем на предыдущее обновление.
Я не против установки обновлений, я против бессмысленного тупого обновления всего на свете. Это можно сутками сидеть и обновлять. Обновлять нужно только то, что действительно необходимо. Ведь не все обновления одинаково полезны.
Однажды я провозился с обновлением серверов до шести утра, когда появился один из вирусов-шифровальщиков. И мне разрешили на следующий день прийти на работу попозже. ПОПОЗЖЕ!
Обновляться нужно, безусловно. По чёткому расписанию. Критичные обновления можно устанавливать вне очереди. При этом критичность должна быть доказана.
Отдельным сегментом идёт обновление разрабатываемого в компании ПО. Если контора занимается софтом, то софт нужно периодически выкладывать. И потом снова откатывать, потому что без багов программировать ещё никто не научился. С этим нужно бороться. Тестовые стенды, автоматизация.
Постоянно создавать виртуальные машины
Если вы всё время занимаетесь созданием виртуалок и раскатыванием ОС на них, то что-то где-то пошло не так. Автоматизируйте процесс.
Да, сисадмины занимаются этим делом, я тоже. Но третий SQL сервер обычно уже делается из клона. Лень — двигатель прогресса.
Чистить место на серверах
Да, да, засирается место на серверах. Я уже третий год пытаюсь внедрить политику логирования. Чую, что пока я вручную чищу логи, политики логирования так и не появится.
Не должен админ чистить место на серверах! Если разработчик внедрил сервис и не позаботился о ротации логов или слива их на лог-сервер, то сервис нужно отправлять на доработку.
Снимать tcpdump
Сервис перестал работать. Работал три года, а вчера перестал. А это безопасники какое-то правило удалили, или новый ACL выкатили. Сисадмин снимает tcpdump с обоих сторон, корячится, разбирается что куда не доходит. А потом пишет заявку с описанием того, что стал недоступен нужный порт.
Это конфликт подходов к работе. У админов: работает — не трогай. У безопасников: закроем всё, потом откроем, если кому-то понадобится.
Нужно искать компромисс. Должно быть описание сервисов, что куда лезет, зачем и по какому порту. Документация, схемы потоков.
Траблшутинг всегда занимает много времени.
Оптимизировать SQL запросы
Знаете чем занимается большую часть рабочего времени DBA администратор? Оптимизацией SQL запросов, которые написали разработчики. Или поиском запросов, которые влияют на работу сервера БД.
Доходит до того, что уровень знаний системного администратора в SQL может превышать уровень разработчика. Хороший SQL разработчик, конечно, способен сам оптимизировать собственный SQL запрос, но бывают печальные исключения. Обычно одним запросом дело не заканчивается. Несколько раз был свидетелем подобных диалогов DBA и разработчиков:
— У вас незакоммиченные запросы со вчерашнего дня висят! — И что, они вам мешают?
Это восхитительный ответ.
Разработчиков тоже можно понять. Херак-херак и в продакшн. Тикет сделан, сервис работает. Оптимизируем когда-нибудь. Сам 10 лет разработчиком отработал, в курсе...
Дата-майнить
У вас в компании появился Hadoop и отдел Big Data? Сисадмин, н-н-н-на-ка! Разбирайся с нодами, кластерами. Обновлять не забывай.
Срочно выкладывать на сайт что-нибудь
Например, новый договор оферты в PDF.
Сайт разработали какие-то аутсорсеры. Или разработчик давно уволился. И поддерживать работу этого сайта нужно админу. Вернее не нужно, но приходится. Ты же сисадмин/программист/IT-шник (подчеркнуть нужное) — разберись.
Очень часто в эксплуатацию сливают кем-то и как-то сделанные сервисы. Вот я не знал, что есть такая CMS как Moodle, и такая штука как XWiki, и Seafile. Теперь знаю.
Внезапно программировать
Я считаю, что системный администратор должен быть подкован в программировании. Нужно уметь писать bash-скрипты, кодить в powershell, питонить в конце концов. Разбираться в чужом коде. Но иногда приходится программировать там, где ты не должен программировать.
Какой можно провести пример? Знаю, что в крупных компаниях системные администраторы пишут собственные драйвера, модули и патчи к ПО. Про работу с SQL я уже писал. Когда-то давно мне приходилось писать на Ruby, чтобы исправить работу плагина для redmine. Приходилось на питоне править код vCenter, чтобы починить работу SMB 2.
Делать чужую работу
- Верстать страничку.
- Править XLS файл.
- Перекачивать MySQL базу данных с одного сервера на другой.
- Сканировать документы в почту.
- Устанавливать приложения на телефон.
- Разгружать газель.
- Чинить кофеварку.
Обычный день сисадмина
И вот ты выходишь на работу после бессонной ночи из-за обновления винды. По дороге заезжаешь в ЦОД поменять диск. Приходишь в офис, чистишь вирусы на телефоне коллеги, накатываешь две виртуалки, одну с виндой, вторую с убунтой. Чистишь место на одном сервере, на другом не знаешь что чистить и тупо добавляешь места. Снимаешь tcpdump, выясняешь, что безопасники перекрыли доступ к DNS удалённому офису, ругаешься с ними по телефону, сам прописываешь доступ в ACL. Настраиваешь почту на телефоне новому сотруднику и показываешь ему адрес корпоративного сайта с разделом HOWTO. Чинишь кофеварку. Меняешь воду в кулере. Помогаешь по телефону найти сотруднику кнопку DEL на маке. Правишь SQL запрос в БД. Объясняешь коллеге, что в файл XLS нельзя выгрузить 120000 строк из 1С, и нет, это не 1С сломался. Восстанавливаешь из бэкапа базу сайта, потому что разработчики всё сломали и бэкап сделать не подумали. Заполняешь какую-то анкету для руководства. Добавляешь места на почтовый ящик сотрудника, потому как все 4 Гб заняты важной корреспонденцией и чистить ничего нельзя. Берёшь с собой новый диск, чтобы завтра заехать в другой ЦОД и поменять. Снимаешь лыжи...
Утрирую, конечно. Преувеличиваю, не всё так печально, потому что ты не один. И выходные бывают.
Чем должен заниматься системный администратор?
Системный администратор отвечает за систему, которую обслуживает. И эту систему он должен привести к такому состоянию, чтобы она была отказоустойчивой.
Ломаться будет всё. Будут гореть ЦОДы и электроподстанции, будут падать сервера и роутеры, дохнуть диски и прочее железо. Телефонные кабели будут красть охотники на медь, экскаваторщики будут копать именно там, где протянута ваша оптика. Периодически разработчики будут случайно дропать базы, а бухгалтеры удалять не тот год в 1С. (Ничего из вышеуказанного не придумал.)
Конечный пользователь системы всего этого не должен заметить.
Как этого добиться? Никого не волнует. На это вопрос и должен ответить сам себе системный администратор. Учитесь, читайте, перенимайте опыт, экспериментируйте.
