Ніколи не помиляється той, хто нічого не робить. Головне вчасно помітити помилку та виправити її. Тим більше коли мова йде про роботу 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.