Ваш хост має відкривати тікет першим.
На нашому desk багато тікетів відкриваємо ми, за власним моніторингом, до того як клієнт щось подасть. Ось операційна модель за цим: інженери з іменем, що стоять усередині інфраструктури, а не черга, що чекає на її краю.
У цій статті 3 розділів
- На нашому desk багато тікетів відкриваємо ми, за власним моніторингом і виявленням безпеки, до того як клієнт щось подасть.
- Модель має чотири ходи: ми відкриваємо тікет, інженер з іменем володіє ним з кінця в кінець, ми вбудовуємо інструменти у вашу операційну діяльність, а найбільша робота виконується як проєкт, поза тікетами.
- Межа чиста: ви ведете свій бізнес і свій застосунок. Ми експлуатуємо і будуємо все під ним.
- Ніщо з цього не є рівнем чи доповненням. Так працює desk.
Почніть зі сповіщення, якого ви не надсилали. Тікет уже відкритий, уже має власника, і перше повідомлення в ньому від нас. Якщо ви коли-небудь мали лише хостингову підтримку, яка чекає на дальньому кінці черги, цей досвід не вкладається в голові першого разу.
Багато наших тікетів починаються саме так, бо операційна модель побудована так, щоб рухатися першою.
Чотири ходи команди, розгорнутої наперед
Ми відкриваємо тікет першими
Моніторинг і виявлення безпеки підключені до дії, тож перше повідомлення в тікеті часто наше.
Людина з іменем володіє ним з кінця в кінець, без рівнів
Ті самі інженери, які монтують сервери в стійки, відповідають у каналі. Жодної стіни L1, жодних передач між рівнями. Стосунки з людиною, а не з чергою.
Ми вбудовуємо наші інструменти у вашу операційну діяльність
Найчіткіша ознака моделі: ми побудували для клієнтів поверхні керування self-service над інфраструктурою, яку експлуатуємо, тож їхній персонал керує щодня, а ми володіємо інфраструктурою під сподом. Повна історія тієї збірки: ми побудували VPN Control Center для власної команди агенції.
Найбільша робота виконується як проєкт, поза тікетами
Коли співпраця переростає чергу (міграція платформи, переархітектура), вона стає обстеженням, зеленим світлом і playbook для cutover. Це міграція є проєктом, а не тікетом.
“День у день це виглядає як команда інфраструктури у штаті, яка до того ж володіє обладнанням і мережею, на яких усе працює.”
Хто що робить
Межу варто сформулювати точно. Наше: metal і все під застосунком: провізіонування, міграції та їхні cutover, архітектура безпечного доступу, staging і pre-production, конвеєр спостережуваності, SAN і мережева fabric, стан backup і DR, інженерія продуктивності й безпеки. Ми беремо відповідальність за рівень, а не лише за тікет. Їхнє: застосунок і бізнес-логіка: що випускати і коли, їхній код, їхня модель даних, їхнє рішення про реліз. Ми сидимо поруч на деплої. Це все одно їхній деплой.
| ВИ ВЕДЕТЕ | МИ ЕКСПЛУАТУЄМО І БУДУЄМО |
|---|---|
| Ваш застосунок і його код | Усе під ним: обчислення, SAN, мережева fabric |
| Вашу модель даних і бізнес-логіку | Платформу бази даних, її резервні копії, її стан DR |
| Рішення про реліз: що виходить і коли | Рівень staging, деплой, playbook для cutover |
| ДЕ МЕЖА РОЗМИВАЄТЬСЯ, НАВМИСНОЩоденну операційну діяльність вашої команди | Поверхні керування, якими працює ваша команда |
Межа розмивається в одному свідомому місці: ми дедалі частіше будуємо інструменти, які дозволяють вашій команді самостійно обслуговувати себе на краю нашого рівня, щоб ваші люди впевнено працювали поверх інфраструктури, яку їм не треба розуміти. Ми не віддаємо runbook і не йдемо. Ми віддаємо поверхню керування і лишаємося.
Хто купує це саме так
Домінують медіа і платформи видавців, бо швидкість релізів і піки трафіку для них екзистенційні. Одразу за ними цифрові агенції, які обслуговують власних кінцевих клієнтів, бо не можуть собі дозволити виглядати маленькими перед клієнтом. У суміші є й підприємства з кількома дата-центрами. Емоція покупця різна, але прохання щоразу те саме: будьте нашою інженерною командою, а не нашим help desk.
Час реагування опублікований на нашій сторінці підтримки. Ця стаття про те, хто рухається першим і хто володіє роботою.
Прямі відповіді
Що насправді означає проактивний моніторинг сервера?+
Що виявлення підключене до дії на боці провайдера. На нашому desk багато тікетів відкриваємо ми за моніторингом і виявленням безпеки, до того як клієнт щось подасть.
Чи отримую я виділеного інженера з managed-хостингом?+
Тут інженер з іменем володіє проблемою з кінця в кінець, і та сама команда, яка монтує обладнання в стійки, відповідає в каналі. Системи рівнів немає. Модель є людиною, а не чергою.
Що відбувається, коли щось ламається о 3-й ночі?+
Моніторинг підключений так, щоб відкривати тікет, тож о 3-й ночі перше повідомлення зазвичай наше. Час реагування є на сторінці підтримки; якщо вашому навантаженню потрібне конкретне зобов’язання, ми визначаємо його разом з вами.
Чи може моя власна команда й далі керувати речами сама?+
Так, навмисно. Ми будуємо для клієнтів поверхні керування над інфраструктурою, яку експлуатуємо (керування користувачами, доступ, щоденна операційна діяльність), тож ваша команда керує, а ми володіємо інфраструктурою під сподом.
У чому різниця між managed-хостингом і власною командою ops?+
У межі. Ви ведете застосунок і бізнес, ми експлуатуємо і будуємо рівень під ним, а найбільша робота виконується як інженерні проєкти, а не тікети.
Перше повідомлення має бути нашим.
Інженери з іменем, без рівнів, усередині інфраструктури, на якій працює ваш бізнес.
Поговоріть з інженеромВи дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером