Пост полезен для системных администраторов и начинающих инженеров Operations. Поехали!
- Вы назначаете ip адреса руками. Для всего. Да, я согласен что в ряде случаев это имеет смысл — например для критически важных элементов инфраструктуры. Но для большинства серверов, абсолютно всех рабочих станций, сетевых телефонов, принтеров и пр — используйте DHCP.
- Для обращения к серверам или другим элементам инфраструктуры, имеющим сетевой интерфейс вы используете IP адреса а не DNS имена. Да ладно, в 21 веке поднять внутренний DNS сервер вопрос от 10 минут до получаса. Запоминать осмысленные имена куда легче и работать с ними проще чем с серверами. Например, при переезде почтового или файлового сервера на новый адрес вам не нужно бегать по всем машинам и менять настройки руками, молясь чтобы вы ничего нигде не забыли. Если у вас настроено имя, вы просто меняете привязку в одном месте и все!
- У вас везде Windows и ничего более. Да, если вы оголтелый виндузятник который по религиозным соображениям не желает изучать ничего другого — возможно. Но тогда вы упускает целый класс решений которые на Linux системах сделать проще, удобнее или вообще можно сделать только на них. не надо так. используйте сильные стороны каждого инструмента.
- Сетевая шара у вас на обычном компе или на сервере но без разделения прав. Обычно выглядит это так — стоит обычный компьютер с самым большим диском, одна его папка открыта по сети на доступ всем желающим. В итоге, как только его владелец уходит вечером домой и выключает компьютер, доступ пропадает у всех. Не говоря уже о том что кто угодно получивший доступ в сеть может брать что угодно, класть что угодно и тд. Первый же шифровальщик в сети покажет вам как вы были не правы.
- У вас более 10 компьютеров на предприятии и вы все еще не используете Active directory. Конечно, это так чудесно раз за разом биться лбом о то, что на компах есть разные не связанные учётки и чтобы открыть доступ с А на Б вам надо или давать доступ «всем», либо держать на обоих компах одинаковый список учеток с одинаковыми паролями.
- Все ваши принтеры подключены локально к компьютерам и шарятся по сети. При том что версия с сетевым интерфейсом стоит тысяч на 5 дороже, а какой нибудь отдельный принт сервер в виде маленькой коробочки стоит вообще копейки. Но нет, зачем, просто будем мучится с тем чтобы расширить все всем и если у кого то подвис комп или кто то ушел домой, его принтер недоступен. особый смак это для сотрудника, к чему компьютеру подключен расшаренный принтер — вокруг него постоянно толкутся те, кому надо забрать то что они только что отправили на печать.
- У вас крупная (от 100 и более машин) сеть но вы все еще не разделяете ее на подсети по функциям. Как это чудесно когда у вас пользователи, сервера и гостевой wifi в одной сети. что же может пойти не так?) как чудесно что сервер баз данных или сервер 1с вы вынуждены закрывать от всех его собственным фаерволом кроме узкого круга ip адресов бухгалтерии вместо, с помощью его собственного фаервола, вместо того чтобы прописать запрет ходить с гостевого wifi куда то кроме интернета.
- Вы принципиально используете только бесплатные решения. даже если платная фича стоит 10 долларов в месяц (один обед в Макдак). Ведь лучше потратить кучу времени и сил чтобы влезть в бесплатный тариф или вообще собрать на коленке аналог из говна, палок и синей изоленты, чем купить готовое решение.
- У вас есть сервер (а) и все они bare metal, то есть никаких виртуалок. Конечно если вы какой нибудь финтех или у вас real time service, тут вопросов нет, но что то мне подсказывает, что это не так для большинства читателей. поэтому давайте у нас на одной железке с одной ОС будет стоять и почта, и 1с, и файл сервер и что нибудь ещё. И в итоге когда потребуется перезагрузить сервер, так вы поставили новый драйвер для 1С ключа, страдать будут все. Да ладно, уже лет 10 на рынке есть решения по виртуализации на любой вкус и цвет. хотите windows — Hyper V. хотите Linux — qemu, proxmox, ovirt (для особых ценителей можно и virtualbox прикрутить). наконец для любителей энтерпрайза есть свободные версии esxi.
- Ваш сетевой стек построен только на дешевом железе для домашнего использования. Конечно, зачем нам управляемые свитчи или роутер который умеет чуть больше чем просто работать NAT машиной, зато дёшево и все привычно, как дома.
- У вас уже куча инфраструктурного железа но нет выделенной серверной комнаты и стойки. Все ваше добро валяется на полу, разложено по деревянным или железным складским стеллажам. Нет ни нормального подведения кабелей сети и питания, нет закрывающейся дверцы… Что такого? — спросите вы. Ну что же.. Представьте горку из 5 работающих серверов, один поверх другого. Пусть они будут в форм факторе 2U. Вам срочно потребовалось провести профилактику 5-го, самого нижнего. Удачи вам его вытащить, не прервав работу 4-х сверху!
- У вас больше 3 серверов и вы все еще без мониторинга. Да, зачем нам знать что до полного заполнения дисков на сервере почты осталось 2-3 дня?) или зачем нам информация что в RAID массиве диск вывалился и сервер летит вперед на одной ноге?
- Все не очевидные решения хранятся лишь в вашей памяти. Ведь это так весело спустя пол года вспоминать — как же я блин это в прошлый раз чинил или почему это именно так настроено? Поверьте, поднять на сервере какую-нибудь простую wiki систему типа Dokuwiki — дело 10-15 минут. Зато потом времени сил и нервов она вам сэкономит — уйму!
- Под каждую новую задачу вы собираете решение из «говна и палок». См пункт выше про платные решения. Но все таки накину на вентилятор примерчик — зачем нам железо с резервированием по питанию и выделенным интерфейсом управления, чтоб можно было перезагрузить его, не доходя ногами, когда можно на базе обычного системника собрать что-то что вроде работает, даже почти не перегревается и если надо заменить ему диск, придется всего лишь разобрать пол корпуса.
- У вас много сервисов но в каждом своя база пользователей для авторизации. Конечно, зачем нам AD/ LDAP /RADIUS, когда можно просто при приходе нового сотрудника заводить ему 100500 учеток, настраивать в каждой права по памяти и тд, вместо того чтобы завести 1 запись и навесить ему несколько групп.
- В ваших серверах очень надежные диски а потому raid вам не нужен, зачем тратить деньги. И вообще этот сервер стоил вам кучу денег, надо использовать то что есть по полной! Ну да, это до первого отказа диска по браку или просто вы продолбаете растущее число сбойных секторов (мониторинга то нет). И привет данные! Уже ни прочитать, ни восстановить…
- Резервное копирование (если оно есть уже хорошо) сделано на базе пачки скриптов, результат работы которых никак не проверяется и не мониторится. И в один прекрасный день, вы понимаете- что Ваш архив с резервными копиями 1С не распаковывается.. Или распаковывается но внутри у вас шлак, который 1С отказывается читать.
- Вся ваша автоматизация в виде скриптов- лежит в лучшем случае на файл сервере в специальной папке IT отдела. И каждый меняет эти скрипты по своему желанию. Или еще круче- каждый держит у себя на машине свои наработки и в случае чего Вы начинаете вспоминать — так, а этот скрипт вроде писал Леха/Вася/Миша — у него там была последняя версия с исправлениями… А Миша в отпуске или уволился.
Опомнитесь — есть системы контроля версий. Самая популярная — Git. Поднимите свой сервер, начните работать с облачными- не важно! Есть версионирование, есть история, есть возможность хранить отдельно стабильные версии и еще сырые доработки. - Ваши пароли от всего лежат в виде текстового файлика или Excel таблички.. Бинго! Во первых структурирование там так себе, а во вторых, попади этот файл куда не надо и вы, пардон, с голой жопой. Возьмите хотя бы KeePass. Уже лучше будет. А вообще зайдите в гугл и поищите на тему Password Management.
- Вы не тестируете изменения прежде, чем применять их на боевой системе. Вы не строите план изменений, Вы не предусматриваете себе пути отхода. “Не сцы, друг, я 100 раз так делал!” И в следующее мгновение, криво скачанное и не проверенное обновление вешает намертво Ваш сервер Баз данных и вы понимаете что планы на выходные только накрылись медным блестящим тазиком. Сделайте себе миниатюрный стенд, который если и не воспроизводит всю вашу рабочую боевую среду, то хотя бы ее ключевые элементы. И тестируйте все сначала там, благо в наше время, когда есть виртуальные машины, git, удобные средства хранения документации это легко! Приучите себя формировать план из 3 пунктов — как мы будем вносить изменения, как мы будем тестировать что изменение прошло успешно и как мы будем откатываться если что-то пошло не так.. И проверяйте этот план на тестовой среде. Причем как вперед, так и назад. Поверьте — спасёт много ваших волос от седины или выпадения!