Никогда не ошибается тот, кто ничего не делает. Главное вовремя заметить ошибку и исправить ее. Тем более, когда речь идет о работе IT-инфраструктуры компании, где даже несущественная ошибка системного администратора, бухгалтера или менеджера по продажам может полностью остановить ее работу на неопределенный период.

Мы попросили одного ведущего специалиста по администрированию наземной и облачной инфраструктуры, с опытом работы в разных компаниях, поделиться самыми популярными факапами, которые совершают пользователи при работе в облаке. Надеемся они уберегут вас от «грабель», на которые уже наступили ваши коллеги по цеху.

Факап 1. Зачем вы удалили мою виртуальную машину

Хорошо, когда у компании много сисадминов или технических специалистов, но не в этот раз.

Помню, как после окончания университета, я работал в компании, которая занималась производством металлопластиковых окон. Наш IT-директор решил мигрировать с собственного «железа» в облачную инфраструктуру. Для этого мы взяли на тест два облака. Один из наших системных администраторов создал в одном из облаков виртуальную машину и настроил ее. Через некоторое время обнаружил, что машинка исчезла. Он позвонил в техподдержку облачного оператора, и спросил: «Зачем вы удалили мою ВМ?». На что ему ответили: «Мы ничего не удаляли, это не входит в правила нашей работы». Через некоторое время, другой системный администратор обратился в техподдержку оператора и попросил помочь ему настроить в другом облаке V-Storage. Воспользовавшись моментом, технический специалист решил уточнить не удалил ли он случайно виртуальную машину, созданную его коллегой. На что получил отрицательный ответ. Естественно, сотрудники облачного оператора не могли пустить на самотек эту ситуацию, посмотрели по логам и увидели, что «тачку» удалил кто-то из наших сисадминов. Они еще долго выясняли кто прав, а кто виноват, но в конце концов стало ясно, что ВМ-ку удалил второй админ.

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

Факап 2. У нас на «железе» все работало, почему мы должны что-то переделывать

Ортодоксальные сисадмины привыкли строить инфраструктуру по образцам 10-15 летней давности, когда на одном сервере «крутилась» ERP, SQL-база данных, терминальный сервер, почтовик и сайт. В таком первозданном виде, они хотят перенести сервер в облако, наивно полагая, что все приложения будут идеально работать. Но не тут-то было. После миграции в облако, начинает тормозить терминальный сервер, и как показывает практика, ему не помогает увеличение оперативной памяти или процессоров. Еще бы, в облаке все устроен иначе, чем на «железе». Необходимо максимально дробить сервисы на более мелкие, которые будут делить между собой функционал.

В таком случае я рекомендую строить терминальную ферму. Начиная с 2012 редакции Microsoft переделал полностью свою службу терминалов с расчетом на то, что при большой нагрузке сисадмин будет разделять нагрузку на насколько виртуальных физических хостов, или виртуальных машин. Это позволяет более гибко масштабировать нагрузку и более удобно проводить техобслуживание и администрировать инфраструктуру.

Факап 3. Я выключил компьютер, и всех выбросило

В 2016 году я работал системным администратором в компании, которая продавала осветительную технику. Я тогда еще плохо знал специфику работы с облачным сервером и не всегда мог решить какие-то проблемы самостоятельно.

Помню, как под конец дня наш бухгалтер Людмила Ивановна, женщина лет 45, закончила работу в программе для бухучета, нажала кнопку «выключить сервер», и всех остальных сотрудников, которые работали в программе, просто выбросило. Как оказалось Людмила Ивановна перепутала кнопки «завершение сеанса» и «завершение работы». Но это мы уже выяснили после того, как я написал тикет в службу поддержки облачного оператора. Хотя мы были уверены, что ошибка на стороне оператора.

Кстати, такие факапы случаются сплошь и рядом. Поэтому лучше все таки обучать сотрудников правилам работы с облачным сервером.

Факап 4. Если мы работаем с облачным оператором, все вопросы безопасности ― его головная боль

В том же 2016-ом, у нас случилась еще одна проблема, но уже более масштабная и с неприятными последствиями. Все сотрудники нашей компании были уверены, что если наши сервисы и приложения находятся в облаке, информация будет автоматически защищена от вирусов-шифровальщиков, хакерских атак и человеческих ошибок. Ведь это работа оператора ― следить за безопасностью в облаке и...делать бэкапы.

И так, в один прекрасный день, я не смог зайти на наш виртуальный сервер. Ввел логин и пароль, но ничего не происходило. Позвонил в техподдержку облачного оператора и описал проблему. Их специалисту удалось зайти на сервер, но то, что он там увидел меня шокировало ― все наши виртуальные машины были «пошифрованы».

Дело в том, что любая виртуальная машина, которая выходит в интернет, имеет открытый RDP-код. Она подвергается подбору паролей со стороны ботов, которые по интернету сканируют все адреса подряд. Если сканер портов находит открытый порт ― начинает подбирать пароли. Поэтому нужно изменить стандартный порт и ставить сложные пароли. Как правило, большинство пользователей этим правилом пренебрегают. Среди них были и мы. Бэкапы тоже не делали, потому что думали, что их делает оператор. Да, технические специалисты облачного оператора обеспечивают безопасность инфраструктуры на аппаратном уровне, но они не создают резервные копии данных клиента. Они не имеют доступа к вашей инфраструктуре и к вашим данным. Если системный администратор не будет самостоятельно создавать резервные копии, а сотрудники компании не будут придерживаться основных правил информационной безопасности в интернете, в случае форс-мажора компания потеряет все данные.

Чтобы подобных ситуаций не возникало, я советую делать бэкапы автоматически, по заранее заданному бэкап-плану и придерживаться «правила 3-2-1»: делайте три резервных копии данных, храните их на двух разных носителях (например, облачное хранилище и жесткий диск) и одну ― на удаленной площадке, скажем, в облачной инфраструктуре.

Факап 5. Мы вносим изменения в сайт, а они не отображаются

Еще одну забавную историю я услышал на днях от своего знакомого программиста. Полгода назад они перенесли в облако сайт. Миграция прошла мягко, без «косяков», а сайт стал работать намного быстрее. Неделю назад, программисты начали проводить ряд изменений на сайте, а они не отображались. Написали тикет в техподдержку облачного оператора и объяснили проблему. Начали разбираться, оказалось, что программисты не перенастроили DNS-записи домена, и все эти полгода сайт работал на старом хостинге.

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

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

P.S. Что еще вы бы хотели узнать про облачные технологии? С какими нюансами в работе с облаком вы сталкивались? Свои вопросы и истории пишите нам на электронную почту sales@gigacloud.ua.