Аудит ИТ-инфраструктуры — как быть новичку

Привет, %username%! Готов поспорить, что рано или поздно все сисадмины относительно небольших компаний сталкиваются с такой волшебной задачей от руководства, как составление проекта развития ИТ-инфраструктуры компании. Особенно если тебе предложили должность и сразу же попросили составить план развития и бюджетирования. Вот и мне однажды поставили такую задачу. О всех подводных камнях, с которыми можно столкнуться, я и напишу. Всем заинтересовавшимся велкам под кат!


Сразу поясню, что вы тут не найдете советов о том, какое оборудование выбирать для тех или иных решений, какие программные продукты выбирать, open source или платное ПО, с какими интеграторами общаться стоит, а с какими нет. Это все полностью индивидуально и будет напрямую зависеть от вас и того, что в итоге вы хотите — залатать дыры в текущем корыте или построить ИТ-инфраструктуру таким образом, чтобы любая задача сводилась к нажатию кнопки “СДЕЛАТЬ ХОРОШО” (да я ленивый).


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


Вот собственно примерный список проблем, с которыми можно столкнуться при проведении аудита ИТ-инфраструктуры:


1. Отсутствие тех, у кого можно хоть что-то спросить — именно такая проблема встала передо мной, когда руководство поручило провести аудит с целью улучшения инфраструктуры в целом. На тот момент я являлся самым старым сотрудником отдела компании и поинтересоваться мне было просто не у кого. По этой причине времени на ковыряние и попытку понять “за каким же это хреном сделано” было затрачено не мало, ведь пока я был простым сисадмином меня почти не посвящали в тонкости организации ИТ-инфраструктуры.


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


3. Отсутствие четкого (документированного) описания текущей инфраструктуры — увы (!) этого не было никогда ранее. Никто и никогда не составлял банальную карту сети офиса. Не описывал как организована связь между филиалами (коих более 10 штук по всей стране). Я уже не говорю про банальную маркировку кабелей на маршрутизаторах.


4. Полное отсутствие документации — вообще! Абсолютно никакой документации не велось в отделе никогда. И это категорически печально. Ведь банальные копии договоров (на телефонию, интернет, обслуживание 1С, аренду хостинга и прочее) хотя бы в электронном виде должны быть в отделе. И это одно из обязательных условий, ведь любой сотрудник отдела ИТ должен знать, к кому обратиться в случае если упал интернет в другом регионе (где время +3 к Москве).


5. Отсутствие общей базы паролей — все пароли были разные и менялись от случая к случаю. Весь этот ворох приходилось держать в голове, т.к. “все что записано однажды — может быть и считано”. Для того, чтобы предоставить новому сотруднику определенный доступ, необходимо переписать в почте (или на бумажке) все логины и пароли и передать их лично ему. А если ты еще не правильно пароль вспомнил… Ужас!


6. Отсутствие информации о том, как все организованно в регионах — имелась информация лишь о том, сколько там человек, кто руководитель и… всё! Т.е. имелась просто абстракция под названием “Региональное представительство в городе Мухосранске, где сидит 15 человек”. Никто никогда не задавался вопросом, как там устроена сеть, какие у нее слабые места, как происходит доступ сотрудников представительства в сеть Интернет, как организован доступ сотрудников к сетевым ресурсам центрального офиса.


И это еще не полный список, т.к. таких косяков просто огромное количество. И все они встретились мне на пути. Одним из тяжелейших моментов могу назвать тот факт, что я этим занимался впервые и ударить в грязь лицом не хотелось.


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


А теперь подробнее о том, как я советовал бы преодолевать все трудности


Я не стану напоминать о том, что необходимо сделать инвентаризацию для того, чтобы понимать с чем работаешь, что является устаревшим, что можно заменить на более производительное. Это обязательное мероприятие. А вот о том, что после переписи всего оборудования надо все разделить всё на категории (активное сетевое, workstaion, bussiness-critical servers and service) напомню. При наличии доступа к административной панели сделать бэкапы конфигураций, описать “что”, “зачем” и “для чего” настроено в конкретной железке, переписать все сетевые адреса серверов, управляемых железок (да простят меня господа сетевики), сетевых хранилищ, принтеров и всего, что имеет доступ к сети (ну кроме рабочих станций).


Следующим этапом можно попытаться составить примерную схему того, как устроена сеть на план-схеме этажа, чтобы понимать где может быть бутылочное горлышко. В моем случае была проблема в том, что сеть этажа поделена на две части и в дальней от серверной части были проблемы с сетью, а оказалось все банально — не экранированная витая пара лежала вместе с силовой линией этажа бизнес-центра напряжением на 220 и 380 вольт — какая к черту сеть, ребята. После этого можно приступать к анализу железа.


Анализ железячной составляющей это одно из важных мероприятий. Необходимо понимать, насколько актуально на текущий момент времени используемое железо (как сетевое и серверное, так и пользовательские ПК). Обычно на этом этапе выясняется (с поддержкой от бухгалтерии, а так же коммерческих отделов), что вся bussiness-critical информация хранится в виде документов Excell на сервере, у которого жесткие диски работают уже третий гарантийный срок (!) и все удивляются тому, что “файлы по сети медленно открываются” и сам сервер шумит дисками как больной психиатрии стучащий ложкой по кастрюле. А сетевые железки сняты с производства еще за год до того, как их купили в компанию и по отзывам они ужасны. Или например wi-fi в офисе поднят на точках доступа, которые по всем отзывам считаются такой дрянью, которую врагу не пожелаешь.


Далее, необходимо оценить текущие серверные мощности


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


Виртуализируйте все!


Когда парк ваших серверов и сервисов достигает критической массы и вы вынуждены заходя в серверную смотреть, что это за систменик или тыкаться по KVM в поисках нужного сервера, то вам явно требуется виртуализация. Все системы, которые можно запустить на виртуалке необходимо перевести в виртуальную среду (всяческие СКУДы, сервер корпоративного портала, корпоративное облако, etc). Современных, а главное удобных инструментов для этого предостаточно (VMware, Proxmox, Xen, Hyper-V). Просто определитесь с тем, что вам нужно/нравится/можно купить и запускайте в работу.


Виртуализацию в топку! Даешь только хардвер!


Не виртуализируйте критичные вещи — такие как шлюзы, маршрутизаторы, VPN-сервера используемые для аварийного доступа в сеть, сервера 1С (тут в меня могу полететь тухлые помидоры). Важно здраво оценивать все факторы, руководствуясь которыми вы принимаете решение о том, что загонять в виртуальную среду, а что нет. Идеальных решений не существует.


Организация сетей между филиалами


Вопрос довольно обширный и имеет множество решений. От самого простого — выделять каждому удаленному сотруднику логин и пароль для VPN, дорогого — арендовать L2-сеть у одного провайдера и до безумного — наставить самых различных сетевых железок от разных вендоров, с помощью которых организовать доступ в сеть на местах и доступ к сетевым ресурсам внутри компании (сетевые хранилища и т.п.). Оцените все “за” и “против” и примите верное и лучшее решение в конкретно вашем случае. Для простоты и понимания “что делать” и “как делать” смело приглашайте системных интеграторов и консультируйтесь с ними. За спрос не дадут по шее, а дадут понять как можно решить одну и ту же проблему разными способами (дешево и дорого). Уже после пары-тройки таких встреч вы сможете более точно и более четко описать для себя самого все свои хотелки и возможные способы их решения.


После всех выше описанных работ можно приступить к составлению примерного бюджета. Для выбора конкретных моделей оборудования обращайтесь за помощью в специализированные чаты (сам использовал чаты в Телеграм, т.к. там всегда живой народ и больше шансов получить быстрый ответ; список можно загуглить). Все оборудование, которое вы выбираете рассчитывайте с запасом на перспективу и рост потребностей ваших прямых клиентов — сотрудников компании. Больше общайтесь с руководством на тему дальнейшего развития бизнеса компании. Возможно они сами вам подскажут ответ на то, на что вы не знали ответа.


Вместо заключения


Правильно организуйте работу вашего отдела, особенно когда вас в отделе больше двух человек. Никогда не создавайте такую ситуацию, в которой какие-то вещи завязаны на одно человека. Это ваша точка отказа!


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


И запомните две вещи:


  1. Идеальной инструкции не существует!
  2. Идеальной защиты не существует!

P.S.: На этом все. Жду ваших комментариев и здравой критики.

Поддержать автора
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 22

    –1
    А кто мешал делать документацию и прочее своевременно, чтобы потом не разгребать?
    Не понимаю, простой сисадмин в небольшой конторе, и какие-то сложности с управлением. Другое дело когда контора больше 5000+ сотрудников, из них ИТ под 100…
      +2
      Приветствую, я прекрасно понимаю о чем вы. Только Я оказался в такой ситуации, где все прошлые сисадмины клали болт на свою работу, а руководство просто не выделяло денег на развитие данного сектора компании.
        –1
        Какие деньги нужны, чтобы просто за собой записать что делал? Постоянно слышу такие отмазки…
          +1
          Я не говорю что нужны деньги для написания документации. А деньги в целом не выделялись никогда в этой компании.
            0
            Чтобы что-то сделать, нужно четкое ТЗ, или хорошая мотивация чтобы делать лучше чем указано в ТЗ.
            Зачастую документация вообще не предусмотрена в инфраструктуре, есть только «сделай быстрее чтоб работало»
              0
              Вот именно с таким я и столкнулся — «Сделай так чтоб работало и обязательно вчера»
        +3
        Я так и не понял о чем статья %) прям поток сознания

        «простым сисадмином меня почти не посвящали в тонкости организации ИТ-инфраструктуры..»
        — Вы точно там сисадминили? Обычно только админы и знают тонкости.

        «додумывать варианты направления развития бизнеса в целом»
        — Ох льстите Вы себе, льстите.

        «Полное отсутствие документации — вообще!»
        — и чего удивляться. С таким подходом, ни бюджеты не запланировать, ни защитить.

        «При наличии доступа к административной панели сделать бэкапы конфигураций, описать “что”, “зачем” и “для чего” настроено в конкретной железке, переписать все сетевые адреса серверов, управляемых железок (да простят меня господа сетевики), сетевых хранилищ, принтеров»
        — А я смотрю организация то у Вас небольшая, или Вы знатный мазохист.

        «Необходимо именно оценить серверные мощности.»
        — повторюсь похоже, Вы точно там сисадминили? %)

        «Когда парк ваших серверов и сервисов достигает критической массы и вы вынуждены заходя в серверную смотреть, что это за систменик или тыкаться по KVM в поисках нужного сервера, то вам явно требуется виртуализация.»
        — может начать с банальных наклеек с банальным IP адресом и именем сервера? потом можно уже и виртуализацию %)

        «сервера 1С (тут в меня могу полететь тухлые помидоры)»
        — я еще б и яиц тухлых добавил.

        «Для выбора конкретных моделей оборудования обращайтесь за помощью в специализированные чаты (сам использовал чаты в Телеграм, т.к. там всегда живой народ и больше шансов получить быстрый ответ; список можно загуглить).»
        — божечки. чятики. прям представляю «Люди посоветуйте начинку для центрального узла VPN, асу например, или там клоудроутер какой.»

        «Старайтесь максимально документировать все свои действия на серверах в процессе изменения конфигураций сервисов.»
        — Это называется Change Managment

        «Идеальной инструкции не существует!»
        — конечно нет, для остальных есть ITIL

        «Идеальной защиты не существует!»
        — вот это что было?
          +1
          О да, в чатах и форумах сидят реальные админы :)))
          Первые лет 5 сисадминства я там тоже был, потом перестало на это хватать времени и желания отвечать на глупые вопросы. Сейчас, имея ~18 лет опыта, поиск решения проблемы методом поста в форум вызывает улыбку.
            +2
            Сейчас, имея ~18 лет опыта, поиск решения проблемы методом поста в форум вызывает улыбку.

            На форумах вендоров часто сидят разработчики (Veeam, IBM, Red Hat) и эксперты (Microsoft, VMware), а без контракта на премьер поддержку — это последняя надежда при решении сложных проблем.
              0
              Вряд ли тут шла речь о форумах вендоров.
            0
            Вы точно там сисадминили? Обычно только админы и знают тонкости.

            — Увы, да.

            Ох льстите Вы себе, льстите.

            — Если только самую малость. А по факту от 70% до 95% поставленных задач, касающихся развития именно бизнеса в целом приходилось додумывать (думали всей командой сисадминов).

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

            — И тут я согласен. О документации никогда не думали прошлые старатели.

            А я смотрю организация то у Вас небольшая, или Вы знатный мазохист.

            — Скорее второе ;)

            повторюсь похоже, Вы точно там сисадминили? %)

            — Повторюсь — Увы, да!

            может начать с банальных наклеек с банальным IP адресом и именем сервера? потом можно уже и виртуализацию %)

            — Проходили этот этап, но когда таких наклеечек становится более 20 и ты об них спотыкаешься, ИМХО лучше виртуализация.

            я еще б и яиц тухлых добавил

            — Ну не люблю я 1С. Простите меня ;)

            божечки. чятики. прям представляю «Люди посоветуйте начинку для центрального узла VPN, асу например, или там клоудроутер какой.»

            — ИМХО живые чаты это самое лучшее место где могут дать ценную информацию, ну или пинка под зад чтоб не приставал с тупыми вопросами.

            Это называется Change Managment

            — Да — именно так.

            конечно нет, для остальных есть ITIL

            — в секторе SOHO проблематично внедрять ITIL.

            вот это что было?

            — Это любимая фраза Кевина Митника
              +1
              — Если только самую малость. А по факту от 70% до 95% поставленных задач, касающихся развития именно бизнеса в целом приходилось додумывать (думали всей командой сисадминов).
              У сисадминов, если утрировать, задача одна — обеспечить бэкэнд для стабильной и эффективной работы сервисов необходмых бизнесу.
              Сам бизнес это процесс зарабатывания денег, и их зарабатывают не сисадмины (за исключением профильных бизнесов) так что коллективный брэйншторминг админов над «развитием» бизнеса это либо себе льстят, либо у вас там не только с ИТ но еще и с руководством плохо %)

              — Проходили этот этап, но когда таких наклеечек становится более 20 и ты об них спотыкаешься, ИМХО лучше виртуализация.
              А вы не колхозьте системники в дальней комнатушке, а сделайте шкаф с рэковыми серверами. И даже в этом случае они должны быть подписаны. Перезагрузить нужный сервер среди десятка одинаковых на лицо сравни игры в русскую рулетку где в барабане только один патрон отсутствует.

              — Ну не люблю я 1С. Простите меня ;)
              Зря. В ней Вам зарплату считают. Стабильность сервиса не должна зависеть от люблю/не люблю. А виртуализация все делает стабильнее.

              — в секторе SOHO проблематично внедрять ITIL.
              Если не знать или не понимать ITIL, то его всегда и везде проблематично внедрять. Основной смысл ITIL натягивать его там где он натягивается, и делать по своему, если методики ITIL не подходят. У всех же своя специфика.

              — Это любимая фраза Кевина Митника
              И как Вам Кевин помогает аудит делать?
            0
            — ИМХО живые чаты это самое лучшее место где могут дать ценную информацию, ну или пинка под зад чтоб не приставал с тупыми вопросами.

            А потом объяснять руководству, что это не вы накосячили, а вооон тот парень из чата.
              0
              Ну так своей головой пользоваться никто не запрещает.
              +2
              Господа, все просто.
              Человеческая лень дело такое, он в этой компании был старейшим сисадмином, при этом ни делал ничего по документированию системы — мне за это не платят! А мне что, больше всех надо? etc.
              Как только его сделали руководителем — О! Мне за это платят (зп банально больше), нужно сделать и показать всем какой я молодец, сделал то чего не было!

              Ну еще возможен второй вариант, про инициативу, инициатора и чего-то там еще — но слабо верится.

              По факту, если-б я не записавыл все «входы-выходы», моя-бы работа превратилась в АД! Т.к. серверов уже более 200, и никогда ты не вспомнишь про какой-нибудь крайне редко доставляемый проблемы сервер, через 5-6 месяцев.
              Наверное никогда не устану говорить, админ бывает умный (записывает все) и глупый…

              ИЗМЕНИЛ, ЗАПИШИ!
                +1
                Вы все перевернули с ног на голову. Я на тот момент оказался самым долго работающим админом. И пока я пытался донести до своих начальников в отделе (пока был помощником) что нужно все записывать, в ответ получал одно — тебе надо ты и пиши. Я частично записывал что мог. Но о глобальной документации по инфраструктуре никто ничего не делал.
                  0
                  Пора внедрять сервисдеск.
                    0
                    Ну дык а кому надо, кроме сисадмина? :)
                    Задача инфраструктуры — «чтобы все работало и подешевле». Если лично сисадмину для этого нужна его личная документация — пусть пишет что хочет.
                    Задача «написать глобальную документацию чтобы другой сисадмин мог разобраться» совсем не такая очевидная как первая. Эта задача легко решается в команде сисадминов (= в немаленькой конторе с ИТ-штатом), а у сисадмина-одиночки нет явной причины тратить свое время на какую-то лишнюю документацию.
                    Часто встречаются ИТ-истории с финалом «меня уволили, а другой не смог разобраться».
                    Редко встречаются ИТ-истории с финалом «я задокументировал все хозяйство так что разобраться сможет даже школьник, за это мне повысили зарплату».
                      0
                      Часто встречаются ИТ-истории с финалом «меня уволили, а другой не смог разобраться».
                      Редко встречаются ИТ-истории с финалом «я задокументировал все хозяйство так что разобраться сможет даже школьник, за это мне повысили зарплату».

                      У автора звучит чуть подругому


                      И пока я пытался донести до своих начальников в отделе (пока был помощником) что нужно все записывать, в ответ получал одно — тебе надо ты и пиши. Я частично записывал что мог.

                      А зачем вышестоящим писать. Так претендентов со знаниями на их место из других сотрудников не будет.

                  0
                  Как уже было замечено, поток сознания, ни конкретики «хотите делайте, хотите нет» ни инструментов, ни масштабов применимости., ни стандартов на устанавливаемые платформы, ни вендоров, ни сетевой инфраструктуры. админить 50 пк пойдет, 1000+ однозначно нет.
                  Когда приходишь в контору, не проблемы виртуализации и особенности связи с филиалами обычно вылазят.
                  1. Что и где стоит физически/программно
                  2. Как это все между собой связано т.е. сетевая инфраструктура
                  3. Как между собой п 1 и 2 работают
                  4. Далее выходят информационные системы которые на всем это сидят.
                  А уже после этого собранная информация систематизируется и сводится, какой инструментарий выбрать, а может он уже есть, писать в табличку в ёксель, поднимать wiki/redmine, использовать hp/axios/… или opensource итд и тп, но порядок лично мне больше применим.
                    0
                    Спасибо! Сейчас попал практическую в такую же ситуацию, только инфраструктуру я буду развертывать практически с нуля, включая и выбор железок, практически при полном отсутствии опыта. Поэтому рад любой информации)
                      0
                      Всё зависит конечно от того, что должно будет делать инфраструктура, но рекомендовал бы читать блоки компаний, которые занимаются строительством дата центров и интеграцией. Там вы поймёте на что равняться, даже если вы никогда не получите их бюджетов.
                      Если строить собираетесь то, что потом проверяют другие (рос/технадзор, роскомнадзор, и прочие инспекции (санитарная/пожарная/охрана труда), то сверяйтесь с нормативной документацией и проектами, которые для вас делают. Кстати не стесняйтесь просить руководство выделять деньги на эти самые проекты. Как минимум это будет хорошая документация к тому, к чему вам надо прийти и как надо сделать (там же ссылки на все НПД/НПА, которые для проектировщиков шаблонный текст, а для вас — список литературы). Дальше уже надо понимать в какой вы сфере и что стоите.
                      Статьи подобного рода вам ничего не дадут.
                      https://habrahabr.ru/post/333910/#comment_10326198

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое