Привет, Хабр!
Буквально на днях ISPsystem исполнилось 20 лет. Дата серьезная, основательная.
«А почему бы не вспомнить, как всё начиналось?» — подумали мы и собрали совет старейшин. Тех, кто «был там 3000 лет назад» и застал времена, когда DevOps’ом в мире и не пахло, автоматизацию делали кастомными скриптами, а разработчики порой экспериментировали прямо на проде.
Мы намеренно ушли от формата «юбилейной биографии компании». Во-первых, это скучно — и нам, и вам. Все-таки гораздо интереснее взглянуть на контекст эпохи в целом. Посмотреть, что изменилось. Разобраться в истории развития собственных продуктов и осторожно заглянуть в будущее.
Под катом вас ждут наши ламповые воспоминания о временах, когда деревья были красивыми и большими, а серверные — маленькими и душными.
Управление инфраструктурой: от shell до Kubernetes
В начале нулевых словом «сервер» было принято обозначать нечто железное, настоящее, брутальное. Управлялись такие машины через терминал или COM-порт. В лучшем случае с помощью KVM. Кстати, COM до сих пор используется для работы с железом, у которого нет собственного дисплея — с маршрутизаторами, например.
Если серверов в компании было 1-2, можно было справиться с ними и «ручками». А если машин 5, 10 и больше? Без автоматизации никак нельзя. Слишком много рутинных операций.
Администраторы начали писать специальные скрипты. Как правило, прямо на shell, без излишеств. Но в какой-то момент эти скрипты неминуемо росли и переваливали за 1000 строк кода. Тоже неудобно: если скрипт столкнется с ошибкой в самом начале, вся «автоматизация» пойдет насмарку. Придется, опять же, погружаться в недра кода и искать, что пошло не по плану.
Ближе к 2010 году начали появляться специализированные инструменты автоматизации — Puppet, Chef, CFEngine и т.п. В отличие от императивного подхода, свойственного скриптам (а ну-ка, компьютер, выполни последовательно эти действия), декларативный (добейся желаемого состояния, описанного в файле) гораздо лучше подходит для автоматизации процессов.
Грубо говоря, если в скрипте приходилось писать нечто вроде «добавить строку foo в файл bar», то инструменты вроде Puppet позволяли сформулировать задачу как «в файле foo должна быть строка bar». Соответственно, система не слепо выполняла инструкцию, а предварительно проверяла, есть ли необходимая строка в файле. Если есть — пропускаем. Если нет — дописываем. А если какой-то шаг программа не могла выполнить, все ошибки были видны.
Вместо скрипта на тысячу строк достаточно было составить декларативный файл (в формате JSON, INI в зависимости от системы) на плюс-минус 50 строчек. Его уже гораздо легче поддерживать.
Как и обещали, делимся воспоминанием о былом ИТ:
Когда-то я писал одну программу, которая должна была по сети пакеты пересылать. И она у меня не работала. Запускаешь — и ничего. Кажется: бери и отлаживайся. Но там очень низкий уровень. Ассемблер, прерывания. Никаких логов об ошибках. Например, выполнил код в прерывании, а в регистр, условно, AX пришло значение 10. Что это такое, откуда взялось? Делай с этим что хочешь. Я убил довольно много времени, пока не нашел опечатку в книжке, из которой переписывал фрагмент кода. А подсмотреть было решительно негде, только вникнуть, самостоятельно догадаться. И так было везде: нужна информация? Ищи тех, у кого она есть. Больше никак.
Но одно дело — автоматизировать рутину. И совершенно другое — управлять железным зоопарком. В каждой компании существовал свой стек инструментов для управления инфраструктурой. Под каждую узкую задачу нужно было находить индивидуальное решение. Полуавтоматическое или даже ручное. Грубо говоря, можно было устроиться на работу сисадмином, имея за плечами опыт в несколько лет — и полгода потратить только на освоение новых инструментов. Просто, потому что в прошлой компании ты привык пользоваться кардинально другим набором средств.
Вот, например, нетривиальная задача: из коммутатора А выходит скорый поезд провод и устремляется куда-то в потолок. Куда он идет? Зачем он идет? Загадка. Хорошо, если дисциплинированный коллега при прокладке задокументировал всё в каком-нибудь текстовом файле или даже нарисовал в Visio. Но разыскать этот файл, найти в нем нужное место и расшифровать — это огромные затраты по времени.
Или как быть, если руководство решило перейти на сервера другого вендора? Старые скрипты не подходят, придется разбираться и составлять новые.
Что касается администрирования — в те годы многие вели учёт стоек, IP-адресов и многого другого, например, информацию о занятых/свободных юнитах, в обычных Excel-файлах. Это всё было ужасно неудобно. Куча разрозненных файлов, куча версий, их надо отправлять друг другу по почте и не забывать актуализировать...
А еще в отдел могла нагрянуть бухгалтерия с вопросом, где стоит сервер, купленный три года назад. А никто и не помнит. За это время даже штат мог поменяться. И начинается инвентаризация, беготня. Раздраженный админ заваривает чай и прячется в курилке, чтобы оттянуть момент поиска серийного номера сервера, который 100% загорожен в стойке другими агрегатами. Не прочитать, пока полстойки не разберешь…
Собственно, наш DCImanager вырос из целого набора скриптов и прочих инструментов, которые мы использовали внутри компании для решения подобных задач.
Сегодня нем можно визуализировать стойки. Добавлять свои карты ЦОДа. Когда в компании больше 1000 серверов, возникают проблемы с тем, чтобы понять в какой части зала какая машина стоит. Кроме того, все данные DCImanager получает напрямую от оборудования, а IP-адреса автоматически раздаются серверам из IPAM-модуля.
В сервисе есть модуль учета, в котором хранится и текущее расположение сервера, и по какой накладной он куплен, и когда был поставлен, и вся его дополнительная периферия. Ничего разбирать и выискивать не придется — достаточно проявить чуть-чуть ответственности при заполнении данных. В будущем мы хотим добавить кабельный журнал, чтобы можно было учитывать кабельные соединения между стойками.
Фактически этот сервис построен на фундаменте из нашего личного опыта, который мы затем переработали и сделали доступным для всех пользователей.
Виртуализация
Представьте, стоит в компании железный сервер. На нем нужно поднять бухгалтерию, почту, сайт, различные внутренние службы и т. п. Иметь под каждую задачу отдельную «железку» — расточительно. Держать все в рамках одной ОС — неудобно и небезопасно. Поэтому виртуализация, когда на одной машине могут спокойно уживаться несколько изолированных друг от друга ОС — незаменимая практика.
Раньше цельные машины «нарезались» под ВМ сугубо вручную. Приходилось невероятно много тыкать мышкой по одним и тем же полям. Сейчас этот процесс занимает секунды, а в то время каждую ВМ приходилось настраивать отдельно. Была высока вероятность банальной человеческой ошибки: чтобы создать 10 одинаковых ВМ, приходилось 10 раз повторить один и тот же набор операций. А если машины чуть-чуть отличались, можно было на автомате куда-то не туда нажать. Ошибся? Переделывай. Сейчас виртуальную машину можно описать в виде кода и развернуть по шаблону. Удобно? Бесспорно.
Еще одна важная вещь — набор ISO-образов систем. Если в компании несколько человек занимались виртуальными машинами, даже одинаковые по ТЗ системы могли быть развернуты из разных, слегка отличающихся образов, что создавало проблемы.
За виртуализацию у нас отвечает VMmanager. Как и DCImanager, он фактически вырос из внутренних инструментов автоматизации.
За годы существования в нем поменялось очень многое: интерфейс, интеграции со сторонними инструментами и средствами мониторинга. Под капотом всё тоже постоянно доводилось и модернизировалось. Вместо FreeBSD jail мы перешли на Xen, позднее внедрили KVM. Добавили поддержку Terraform, чтобы хранить инфраструктуру как код.
Раньше приходилось отдельно настраивать мониторинг, различные взаимодействия. Отдельный момент — уведомления. Теперь даже в почту не нужно заходить, все алерты приходят в Telegram.
А тогда все было по-другому:
Однажды в нашем институте, где мы отвечали за инфраструктуру, выключили электричество. Посреди ночи, когда никто не ожидал. Помнится, мы с коллегами как раз культурно отмечали какой-то профессиональный праздник. Через пару часов свет дали, и в наши головы закралась резонная мысль: неплохо бы включить сервер и проверить, что все работает. Итак, поздняя ночь. Я, полный решимости всё починить, добрался до института и хочу пройти в серверную. Охранник, руководствуясь классическим «не положено» и «нельзя в таком виде» отправляет меня восвояси. Что делать? Подчиняюсь. Но на следующий же день, включив наконец злополучный сервер, составляю докладную записку. Дескать: вследствие чрезмерного энтузиазма службы безопасности я не смог произвести необходимые технические работы. Поэтому вся почта ректора за сутки безвозвратно утеряна. В итоге мне официально выдали круглосуточный доступ :)
Биллинг
В условном 2003 году, если вы хотели предоставлять услуги хостинга, пришлось бы писать систему биллинга с нуля, притом только для внутреннего пользования.
Клиент оставлял заявку на подключение услуги. Менеджер или админ обрабатывал эту заявку (вручную настраивал всё, что нужно клиенту), затем информировал бухгалтерию, чтобы там через 1С выставили клиенту счет.
Альтернативный вариант — обратиться к крупному интегратору, который в течение нескольких месяцев будет внедрять биллинг в компании. Коробочных продуктов на рынке было очень мало. Сейчас наш BILLmanager поддерживает много вариантов оплаты, включая карты — а тогда даже системы такой толком не было.
Вот еще одна история от нашего коллеги с одного из его предыдущих мест работы:
Была у нас забавная история с одним иностранным клиентом. По-моему, французским, но за давностью лет ручаться не могу. А у нас, у провайдера, при создании логина пароль генерировался автоматически. Однажды техподдержка снимает трубку и слышит претензию от этого клиента: почему, мол, вы мне выдали в качестве пароля матерное слово на французском?! Мы объяснили ситуацию и предложили поменять его на что-то более цензурное. Представитель клиента тут же вошел в положение и рассмеялся: нет-нет, говорит. Оставляйте какой есть. Неприличный, но зато хорошо запоминается.
В те годы биллинг был сугубо инструментом взаиморасчетов. Современные продукты (и наш в том числе) автоматизирует все процессы, от оставления заявки клиентом до фактического подключения нужной услуги — например, развертывания ВМ. Никакого ручного вмешательства не нужно.
С другой стороны, всеобщая автоматизация породила в новом поколении программистов такое явление как «я не буду этого делать, меня не для этого наняли». Сложно сказать, хорошо это или плохо.
Раньше всё было чуточку иначе. Все спецы в городе друг друга знали. Айтишники были чуть ли не лично знакомы с клиентами и их техническими отделами. Регулярно происходили междусобойчики, общие встречи. И было немыслимо услышать от человека фразу в духе «это не моё дело». Какая бы ни была проблема: прокинуть провод, настроить софт, установить железо, люди охотно соглашались поработать. Отчасти из интереса. Отчасти из профессиональной гордости. Отчасти потому, что больше некому было решить проблему. Они горели новыми идеями, веяниями и бесстрашно шли вперед. В современном ИТ стать первопроходцем, пожалуй, уже не так просто, однако и в нынешних айтишниках все также горит огонь любопытства и страсти познания.
Хотите немного поностальгировать? Поделитесь своими историями в комментариях!