Trench Tales: Плохая или отсутствующая ИТ-документация может оставить вас в растерянности
В предыдущем выпуске Trench Tales здесь, в TechGenix, я рассказывал о своем друге, который много лет занимался ИТ и недавно сменил работу, заняв новую должность управляющего ИТ в публичной компании в Вене, Австрия. Моего друга зовут Мартин Урвалек, и когда он пришел в новую компанию, он обнаружил, что ему не хватает работы. Как мы видели ранее, одной из неотложных проблем, с которыми он столкнулся, была реструктуризация сети компании. Это было вызвано требованием привести сеть компании в соответствие с недавно принятым законодательством ЕС по Общему регламенту защиты данных (GDPR), о котором мы много говорили на этом сайте.
Но это не единственная проблема, с которой Мартин столкнулся на новой должности. Еще один момент, который сразу же поразил его, когда он пришел в компанию, заключался в том, насколько плохо были задокументированы ИТ-системы и процессы компании. И я уверен, что многие наши читатели, работающие в сфере управления и администрирования ИТ, сталкивались с подобными проблемами при смене работы и переходе на новую для бизнеса и организации. Обнаружение того, что ваши предшественники не выполнили свою работу должным образом и оставили после себя беспорядок, который вы должны убрать, — обычное дело, и это неприятно. Чтобы проиллюстрировать, что может пойти не так в этой области, мы начнем с изучения проблем, с которыми Мартин столкнулся в связи с плохой или отсутствующей сетью и ИТ-документацией у своего нового работодателя. Затем мы рассмотрим некоторые различные инициативы, предпринимаемые Мартином для решения проблемы.
Плохая или отсутствующая ИТ-документация: Масштаб проблемы
«Отсутствие документации имеет для меня разные аспекты, — говорит Мартин. «Сфера охвата включает программное обеспечение, инфраструктуру, серверы, клиенты, Active Directory, безопасность и так далее».
— Начнем с разработки программного обеспечения, — сказал я Мартину. "Разработка программного обеспечения? Только встроенная документация внутри кода!» он ответил. «Мы понятия не имеем, какие формулы и алгоритмы использовали бывшие программисты для некоторых задач, что делает реинжиниринг трудоемким и сложным. Модификации существующих программ неизбежно сопряжены с риском, поскольку у нас нет полного представления о связи между различными модулями. Таким образом, исправление в одном модуле может привести к поломке другого, зависящего от него. И у нас много модулей, некоторые из них конца 80-х! Я могу выделить как минимум три эпохи программирования IBM RPG в нашей текущей кодовой базе».
И это еще не все. «Инфраструктура — еще одна проблема, — говорит Мартин. «Наличия списка IP-адресов недостаточно! У нас есть множество компонентов локальной сети, таких как коммутаторы, точки доступа, брандмауэры и почтовые шлюзы, но нет обзора того, как все они взаимодействуют друг с другом, не говоря уже об унифицированной конфигурации и документации по всем различным конфигурациям». Я кивнул головой, так как сталкивался с похожей ситуацией во многих известных компаниях и организациях, с которыми я работал или посещал на протяжении многих лет.
Что насчет серверов? Используют ли они последнюю версию платформы Windows Server? «На самом деле мы как раз сейчас перестраиваем нашу инфраструктуру Microsoft, заменяя Windows Server 2008, — сказал Мартин. А клиентские системы? «Windows 7, но мы их заменяем». И не слишком рано, предложил я.
«Active Directory — еще одна серьезная проблема, — говорит он. Чем больше мы его используем, тем больше на нас влияет отсутствие документации. Например, есть куча объектов GPO, связанных с разными OU, которые мешают друг другу. И у нас даже есть модифицированная политика домена по умолчанию, о которой никто даже не знал». Я поморщился, когда он сказал это, потому что политика домена по умолчанию никогда не должна изменяться. «У нас также есть активные учетные записи пользователей, которые не использовались годами. Я мог бы продолжать и продолжать». Очевидно, там много чего нужно убирать!
«Затем есть охрана, — говорит Мартин. «Прописанной политики безопасности не существует, и пока у меня нет письменной политики, я просто не могу ее придерживаться. Безопасность — это скорее лучшие практики, чем продуманная концепция». Я также спросил его, считает ли он, что его серверы настроены безопасно. «Ну, мы нашли на них много установленных сервисов, которые никогда не использовались и никогда не будут упущены. И, конечно же, они расширяют мою поверхность атаки внутри нашей сети».
Решение проблем с ИТ-документацией
Пришло время перейти к решениям, поэтому я спросил Мартина, может ли он описать, как он планирует решить свою проблему с отсутствующей сетевой документацией, включая то, какие аспекты он считает приоритетными и как он к ним подходит. «Я параллельно выполняю некоторые задачи, — ответил он. «Например, сейчас мы используем инструмент DocuSnap для настройки нашей документации. Этот инструмент позволяет нам автоматически получать некоторую информацию, а также добавлять свою собственную, когда это необходимо. В долгосрочной перспективе я ожидаю получить наше руководство по аварийному восстановлению из информации, которую мы собираем с помощью этого инструмента».
Как насчет любой существующей документации, которую вы найдете? Я уверен, что некоторые из них неполны или даже вводят в заблуждение, если они не обновлялись регулярно. «Да, вся наша существующая документация проверяется, затем ненужные документы удаляются, а документы, подлежащие обновлению, помечаются соответствующим образом. Затем новая и обновленная документация проверяется другим партнером перед ее выпуском. Я ожидаю около шести месяцев, пока все это не будет завершено». Хороший процесс, подумал я про себя, когда он сказал мне это.
«Мы также установили шаблоны для документации, и их необходимо использовать при создании новой документации. Мы постоянно расширяем и улучшаем эти шаблоны». Ага, это еще одна передовая практика, о которой мне нужно помнить, когда я помогаю компаниям навести порядок в своих процессах документации. «Кроме того, мы утверждаем внешнюю работу только тогда, когда документация доставлена и проверена», — добавил он. «И желательно на основе наших шаблонов».
Я закончил свое обсуждение, упомянув, как он говорил о создании руководства по аварийному восстановлению для своего нового работодателя. Я предположил, что это, вероятно, будет незавершенной работой, и Мартин с готовностью согласился. «На самом деле мы проводим тест аварийного восстановления один раз в год для наших сред Windows и IBM, и мы делаем это на основе наших руководств и документации, чтобы обнаружить любые пробелы в этой документации». Теперь, если бы я только мог убедить предприятия и организации, с которыми я общаюсь, сделать то же самое!