Керована підтримка і супровід застосунків
Підтримка працездатності ПЗ, яке вже запущено, у межах вашого SLA і вашої черги тікетів: тріаж, виправлення причин, патч-релізи, оновлення залежностей і платформ, реагування на загрози безпеці та обробка інцидентів. Друга і третя лінії підтримки, які ведуть інженери, що й самі розробляють, тож повторювана несправність виправляється, а не перезапускається.
Чому це проблема партнера
У керованій послузі підтримку легко продати, але важко укомплектувати людьми. Навантаження надходить нерівномірно, потрібні люди, які вміють читати незнайомий код під тиском часу, а щойно ви ставите на підтримку найкращих інженерів, вони стають недоступними для роботи, за яку платять більше. Зазвичай відповіддю стає окремий дешевший рівень, що закриває тікети, нічого не виправляючи, і клієнт помічає це вже за квартал.
Наша відповідь: на підтримці працюють інженери. Вони можуть змінити систему, а не лише описати її, і це єдиний спосіб, яким повторюваний інцидент нарешті перестає повторюватися.
Що ми беремо на себе
Тріаж і діагностика
Беремо те, на що не може відповісти перша лінія, відтворюємо проблему і називаємо справжню причину, а не закриваємо тікет як невідтворюваний.
Виправлення, що тримаються
Дефекти, виправлені в самій причині, з регресійним тестом, написаним на весь клас помилок, а не на один тікет, щоб той самий інцидент не повернувся наступного кварталу.
Релізи та патчі
Патч-релізи випускаються через ваш пайплайн за вашим процесом змін, а залежності, версії фреймворків і середовища виконання платформ підтримуються в актуальному стані, щоб не скотитися до кризи з оновленнями.
Реагування на загрози безпеці
Опублікований бюлетень безпеки щодо компонента, від якого ви залежите, є безумовною підставою для оновлення, а не пунктом беклогу. Ми відстежуємо такі бюлетені, встановлюємо патчі й повідомляємо, наскільки ви були вразливі.
Моніторинг та інциденти
Стежимо за сповіщеннями, які вже налаштовано, додаємо ті, яких бракує, і опрацьовуємо інциденти, а потім надаємо письмовий звіт про те, що сталося і що не дасть цьому повторитися.
Невеликі зміни
Постійний потік дрібних доробок, які тримають клієнта задоволеним, але ніколи не виправдовують окремого проєкту: опрацьовуємо їх у межах тієї самої потужності й на тих самих умовах.
Ваш SLA, чесно оцінений
Ми не публікуємо цільових показників часу реакції та вирішення, бо цифра, вигадана до того, як хтось побачив вашу систему, нічого не варта ні для вас, ні для вашого клієнта. Натомість ми вивчаємо SLA, за яким ви вже відповідаєте перед клієнтом, кажемо, які його частини ми справді можемо взяти на себе і яке покриття підтримки для цього потрібне, а потім письмово беремо це на себе.
Те саме стосується підтримки в неробочий час. Якщо проєкт цього потребує і ми домовилися про це заздалегідь, її забезпечують люди, яких найняли або виділили саме на ці години, а не так, що ми будимо когось і сподіваємося на краще. На інших проєктах ми вже працюємо за європейським, австралійським і тихоокеанським часом США, тож питання в тому, яке вікно вам потрібне, а не в тому, чи це можливо.
Прийняття системи, яку ми не створювали
Це звичайна справа. Досі ми прийняли дев'ять систем, найстаріша з них написана у 2008 році.
Спершу огляд лише для читання
Ми отримуємо доступ до коду, інфраструктури та історії тікетів до того, як починаємо за щось відповідати, і лише дивимося, а не змінюємо.
Письмовий перелік ризиків
Що крихке, що не оновлено, що не задокументовано і що вночі когось розбудить, у порядку впливу на продакшн. Перелік лишається вам, незалежно від того, чи працюватимемо ми разом далі.
Розмова про покриття
Ми вивчаємо SLA, за яким ви відповідаєте перед клієнтом, і чесно кажемо, які його частини можемо взяти на себе, які години для цього потрібні і скільки це коштує, ще до того, як будь-яка зі сторін щось підпише.
Передача, потім штатна робота
Визначений період, коли ми працюємо пліч-о-пліч із тим, хто нині володіє знаннями, а потім беремо чергу тікетів на себе. Якщо знань уже не має ніхто, ми починаємо з огляду ризиків.
Від вашого імені, якщо ви так домовилися
Підтримка зазвичай найпомітніша частина керованої послуги, тому саме тут формат white-label має найбільше значення. Наші інженери можуть працювати зі скриньок і облікових записів, які створите ви, відповідати у вашій системі тікетів і писати звіти про інциденти, які ви пересилаєте без змін; ваш клієнт увесь час має справу з вами. Як це організовано, описано в розділі про white-label розробку, і до підтримки це застосовується так само.
Як формується ціна підтримки
Ціна за людину на місяць, тому ваші витрати передбачувані, і від них можна відштовхуватися, коли ви розраховуєте для свого клієнта вартість договору підтримки. Усі фіксують час у нашому власному порталі, ви бачите години протягом усього місяця, а рахунок формується з тих самих даних, тож є один облік, з яким звіряються обидві сторони.
Коли підтримка поєднується з новою розробкою, зазвичай це одна nearshore-команда, а не два договори, тож тихі тижні в одній частині окупають напружені в іншій.
Запитання про формат підтримки
Що охоплює керована підтримка застосунків?
Підтримка працездатності програмного забезпечення, яке вже працює в продакшні: первинний розбір запитів, що надходять у чергу, відтворення й виправлення дефектів, відповіді на технічні запитання, з якими не впорається перша лінія, випуск патч-релізів, оновлення залежностей і версій платформ, стеження за сповіщеннями та усунення інцидентів, коли щось ламається. Це робота другої та третьої лінії; ваша перша лінія залишається там, де є.
Чи працюєте ви за нашою угодою SLA?
Так. Ми не публікуємо цільові показники реакції та вирішення, бо цифра, придумана ще до знайомства з вашою системою, нічого не варта. Ми вивчаємо угоду SLA, за якою ви вже зобов'язані перед своїм клієнтом, чесно кажемо, які її частини можемо забезпечити і яке покриття для цього потрібне, а потім письмово беремо на себе ці зобов'язання.
Чи можете ви забезпечити підтримку у позаробочий час або чергування?
Так. Підтримку у позаробочий час і чергування ми погоджуємо наперед, фіксуємо в умовах підтримки та забезпечуємо людьми, чий графік роботи їм відповідає, тож нічний інцидент потрапляє до того, хто перебуває на зміні, а не до того, кого розбудили.
Чи можете ви підтримувати систему, яку не створювали самі?
Це звичайна ситуація. Поки що ми прийняли дев'ять проєктів від інших команд, найстаріший з яких написано у 2008 році. Підтримка успадкованої системи починається з огляду в режимі лише для читання та письмового переліку ризиків, упорядкованих за впливом на продакшн, тож перші тижні йдуть на те, щоб зрозуміти, за що ви справді відповідаєте, а не гадати під тиском.
Чи ті самі люди, що підтримують систему, також вноситимуть до неї зміни?
Так, і в цьому суть. Підтримку ведуть інженери, а не окремий рівень, що лише закриває тікети, тож інцидент, який повторюється, можна усунути в його першопричині, а не перезапускати щопонеділка. Якщо у вас з нами є і напрям розробки, і напрям підтримки, вони спільно проходять код-рев'ю та ухвалюють архітектурні рішення.
Як формується ціна підтримки?
Щомісяця, за людину, тож ваші власні витрати передбачувані, і ви можете, відштовхуючись від них, визначити ціну договору підтримки для вашого клієнта. Години фіксуються в нашому порталі й доступні вам для перегляду протягом усього місяця, а рахунок формується з тих самих цифр, тож для обох сторін є одне джерело.
Є системи, які треба підтримувати в роботі?
Напишіть, що це за системи, що обіцяє ваш SLA і де підтримка зараз дається найважче. Ми все прочитаємо й скажемо, які частини можемо взяти на себе, а також назвемо ті, що нам не під силу.