Swarming (Роение) 🐝
Товарищи из serviceinnovation.org пишут: интеллектуальное роение (Intelligent Swarming ) — это более разумный способ объединить людей с работой.
Звучит красиво. Теперь посмотрим, что нам предлагают инновационного и интеллектуального.
Первое, что хочу отметить, нет готовой инструкции, как правильно построить сворминг. Каждая компания идет своим путем.
Каждый «рой» представляет собой небольшую команду, сосредоточенную на входящем потоке заявок от заказчиков.
Severity 1 Swarm(Рой «Критичность 1»)
Основной фокус: Обеспечить немедленный ответ и решить как можно скорее.
Рой «Критичность 1» сосредоточен на наиболее критичных обращениях. Рой координирует решение критичных задач, распределяя их «правильным» людям, чтобы обеспечить решение настолько быстро, насколько возможно. По сути, нечем не отличается от Incident management по ITIL.
Dispatch Swarm(Диспетчерский рой)
▪️ Основной фокус: «сборщики вишни». Какие из новых заявок можно решить немедленно?
▪️ Вторичный фокуc: проверка заявок перед назначением группам поддержки продуктовых линеек.
Диспетчерский рой устраняет ключевой недостаток многоуровневой поддержки: заявки могут быть решены быстро, если попадут к «профильным» специалистам, но они теряются в бэклоге. В результате чего «пятиминутная» задачка по факту может занять несколько дней.
Диспетчерский рой в первую очередь занимается «сбором вишни», игнорируя всё, что невозможно решить очень быстро
Тут нужно понимать, что рой - это кроссфункциональное объединение инженеров, т.e. В рой могут входить инженеры L1,L2 и L3.
Какие это дает дополнительные плюсы?
Специалисты начальных линий быстрее обучаются. Специалисты старших линий становятся ближе к клиентам.
В BMC данный рой решал 30% заявок от общего объема.
Остальные заявки улетали в рой третьего типа.
Backlog Swarm (Бэклог рой)
• Основной фокус: рассмотреть сложные заявки, переданные из групп поддержки продуктов.
• Вторичный фокус: заместить отдельных экспертов по предмету.
Для решения наиболее сложных проблем Backlog Swarm объединяет группы опытных и квалифицированных инженеров, географические и структурные границы не имеют значения. Они получают задачи от специалистов на местах, которым теперь запрещено напрямую обращаться к экспертам индивидуально. Вместо этого они должны передавать задачи в соответствующий Backlog Swarm.
Итого:
Минусы 3-х уровневой системы поддержки
▪️ Разрыв между первой линией и DevOps-командой может приводить к
задержкам маршрутизации заявок и ошибкам их категоризации.
▪️ Отсутствие понимания всех инструментов (DevOps) для младших линий. Старшие линии не в курсе болей клиентов.
▪️ Попытка сформировать жесткую вертикальную и горизонтальную разделённую структуру приводит к созданию барьеров для кросс-функционального сотрудничества, которое является залогом внедрения «правильных» практик DevOps.
Swarming:
▪️ Динамичное кросс-функциональное сотрудничество, объединяющее специалистов с различными компетенциями в команды.
▪️ Гибкая структура команд вместо жёстких иерархических структур.
▪️ Высокий уровень автономии вместо жёстко регламентированных процессов (ключевой пример – «сборка вишни» в Диспетчерском рое).
▪️ Акцент на предотвращении роста бэклога незавершённых задач.
▪️ Кросс-функциональный обмен навыками и опытом между сотрудниками.
Товарищи из serviceinnovation.org пишут: интеллектуальное роение (Intelligent Swarming ) — это более разумный способ объединить людей с работой.
Звучит красиво. Теперь посмотрим, что нам предлагают инновационного и интеллектуального.
Первое, что хочу отметить, нет готовой инструкции, как правильно построить сворминг. Каждая компания идет своим путем.
Каждый «рой» представляет собой небольшую команду, сосредоточенную на входящем потоке заявок от заказчиков.
Severity 1 Swarm(Рой «Критичность 1»)
Основной фокус: Обеспечить немедленный ответ и решить как можно скорее.
Рой «Критичность 1» сосредоточен на наиболее критичных обращениях. Рой координирует решение критичных задач, распределяя их «правильным» людям, чтобы обеспечить решение настолько быстро, насколько возможно. По сути, нечем не отличается от Incident management по ITIL.
Dispatch Swarm(Диспетчерский рой)
▪️ Основной фокус: «сборщики вишни». Какие из новых заявок можно решить немедленно?
▪️ Вторичный фокуc: проверка заявок перед назначением группам поддержки продуктовых линеек.
Диспетчерский рой устраняет ключевой недостаток многоуровневой поддержки: заявки могут быть решены быстро, если попадут к «профильным» специалистам, но они теряются в бэклоге. В результате чего «пятиминутная» задачка по факту может занять несколько дней.
Диспетчерский рой в первую очередь занимается «сбором вишни», игнорируя всё, что невозможно решить очень быстро
Тут нужно понимать, что рой - это кроссфункциональное объединение инженеров, т.e. В рой могут входить инженеры L1,L2 и L3.
Какие это дает дополнительные плюсы?
Специалисты начальных линий быстрее обучаются. Специалисты старших линий становятся ближе к клиентам.
В BMC данный рой решал 30% заявок от общего объема.
Остальные заявки улетали в рой третьего типа.
Backlog Swarm (Бэклог рой)
• Основной фокус: рассмотреть сложные заявки, переданные из групп поддержки продуктов.
• Вторичный фокус: заместить отдельных экспертов по предмету.
Для решения наиболее сложных проблем Backlog Swarm объединяет группы опытных и квалифицированных инженеров, географические и структурные границы не имеют значения. Они получают задачи от специалистов на местах, которым теперь запрещено напрямую обращаться к экспертам индивидуально. Вместо этого они должны передавать задачи в соответствующий Backlog Swarm.
Итого:
Минусы 3-х уровневой системы поддержки
▪️ Разрыв между первой линией и DevOps-командой может приводить к
задержкам маршрутизации заявок и ошибкам их категоризации.
▪️ Отсутствие понимания всех инструментов (DevOps) для младших линий. Старшие линии не в курсе болей клиентов.
▪️ Попытка сформировать жесткую вертикальную и горизонтальную разделённую структуру приводит к созданию барьеров для кросс-функционального сотрудничества, которое является залогом внедрения «правильных» практик DevOps.
Swarming:
▪️ Динамичное кросс-функциональное сотрудничество, объединяющее специалистов с различными компетенциями в команды.
▪️ Гибкая структура команд вместо жёстких иерархических структур.
▪️ Высокий уровень автономии вместо жёстко регламентированных процессов (ключевой пример – «сборка вишни» в Диспетчерском рое).
▪️ Акцент на предотвращении роста бэклога незавершённых задач.
▪️ Кросс-функциональный обмен навыками и опытом между сотрудниками.
👍7
Ушел за хлебом. Вернулся. В руке буханка. А в голове идеи, как создавать и улучшать техническую поддержку.
За прошлый год у меня было два повышения по должности. Теперь управляю несколькими направлениями, в каждом из которых трудятся по доброму десятку инженеров, а то и по два.
Работа поглощает почти целиком и полностью. И будет как-то неприлично не делиться опытом, раз я всех вас тут собрал :)
Что нас ждет впереди?
Поговорим о видах технической поддержки и их подвидах. Мы погрузимся в мир ITIL и узнаем, какие процессы активно используются в российском Big Tech. Знание этих процессов откроет перед вами двери в мир, куда обычным людям путь заказан. Понимание сути этих процессов делает вас профессионалом с особым чутьем и навыками.
ИИ — наше всё. Мы обсудим практическое применение искусственного интеллекта в технической поддержке: как он помогает и кому именно. Копнем глубже в сценарии использования, cможете блеснуть знаниями о методе RAG.
Также рассмотрим тренды в техподдержке и поговорим о том, как строить команды мечты. Нырнем в обслуживание разных вселенных: B2C, B2B.
Не забудем про метрики. Разберемся, как это всё оцифровать и превратить в полезные данные.
Вечный двигатель я вам не обещаю, но то, что вы найдете что-то новое и интересное, гарантирую. Устраивает? Тогда начнем.
Завтра пост по ИИ.
За прошлый год у меня было два повышения по должности. Теперь управляю несколькими направлениями, в каждом из которых трудятся по доброму десятку инженеров, а то и по два.
Работа поглощает почти целиком и полностью. И будет как-то неприлично не делиться опытом, раз я всех вас тут собрал :)
Что нас ждет впереди?
Поговорим о видах технической поддержки и их подвидах. Мы погрузимся в мир ITIL и узнаем, какие процессы активно используются в российском Big Tech. Знание этих процессов откроет перед вами двери в мир, куда обычным людям путь заказан. Понимание сути этих процессов делает вас профессионалом с особым чутьем и навыками.
ИИ — наше всё. Мы обсудим практическое применение искусственного интеллекта в технической поддержке: как он помогает и кому именно. Копнем глубже в сценарии использования, cможете блеснуть знаниями о методе RAG.
Также рассмотрим тренды в техподдержке и поговорим о том, как строить команды мечты. Нырнем в обслуживание разных вселенных: B2C, B2B.
Не забудем про метрики. Разберемся, как это всё оцифровать и превратить в полезные данные.
Вечный двигатель я вам не обещаю, но то, что вы найдете что-то новое и интересное, гарантирую. Устраивает? Тогда начнем.
👍7🔥5
Существуют ли интересные применения искусственного интеллекта в технической поддержке, которые действительно облегчают работу инженеров или улучшают клиентский опыт?
Штош, давайте рассмотрим пять сценариев использования ИИ в технической поддержке, которые уже сейчас демонстрируют свою эффективность:
1. Умный поиск (Intelligent Search) с использованием RAG
Представьте себе ситуацию: вы задаете технический вопрос и вместо бесконечного списка ссылок получаете четкий и лаконичный ответ. Это не фантастика — это реальность с использованием умного поиска на основе RAG. Этот метод сочетает в себе мощные механизмы поиска информации и генеративные языковые модели, которые превращают сложные данные в простые и понятные ответы. Это как иметь личного юриста, который быстро находит нужные законы и объясняет их суть, адаптируя информацию под вашу ситуацию.
2. Предиктивная маршрутизация
Задумайтесь о том, как предиктивная маршрутизация может изменить подход к обработке запросов. Теперь каждый входящий вопрос автоматически направляется к нужному специалисту. Представьте: звонит клиент с проблемой виртуальной машины — и его запрос мгновенно попадает к инженеру по виртуализации. Это не только экономит время, но и повышает качество обслуживания. Согласитесь, приятно знать, что ваш вопрос будет решен именно тем, кто в этом разбирается лучше всего.
3. Саммаризация
Забудьте о длинных цепочках комментариев. ИИ сможет кратко изложить суть обращения, позволяя инженерам быстро понять, что именно требует внимания. Это словно иметь волшебную палочку, которая превращает сложные тексты в ясные и лаконичные отчеты. И теперь у вас больше времени для решения действительно важных задач.
4. Анализ настроений пользователей
Не стоит забывать и об анализе настроений пользователей. ИИ способен уловить тональность обращений клиентов, позволяя технической поддержке быстро реагировать на негативные отзывы. Это значит, что ваша команда всегда будет на шаг впереди, а клиенты — довольны.
5. ИИ для анализа комментариев инженеров по соответствию Tone of Voice компании
И вот мы подходим к финалу нашего путешествия. Как вы думаете, насколько важно анализировать комментарии инженеров на соответствие tone of voice компании? Искусственный интеллект может помочь в этом, оценивая стиль общения сотрудников и обеспечивая единообразие в коммуникации. Это не просто полезно — это необходимо для создания сильного бренда.
Штош, давайте рассмотрим пять сценариев использования ИИ в технической поддержке, которые уже сейчас демонстрируют свою эффективность:
1. Умный поиск (Intelligent Search) с использованием RAG
Представьте себе ситуацию: вы задаете технический вопрос и вместо бесконечного списка ссылок получаете четкий и лаконичный ответ. Это не фантастика — это реальность с использованием умного поиска на основе RAG. Этот метод сочетает в себе мощные механизмы поиска информации и генеративные языковые модели, которые превращают сложные данные в простые и понятные ответы. Это как иметь личного юриста, который быстро находит нужные законы и объясняет их суть, адаптируя информацию под вашу ситуацию.
2. Предиктивная маршрутизация
Задумайтесь о том, как предиктивная маршрутизация может изменить подход к обработке запросов. Теперь каждый входящий вопрос автоматически направляется к нужному специалисту. Представьте: звонит клиент с проблемой виртуальной машины — и его запрос мгновенно попадает к инженеру по виртуализации. Это не только экономит время, но и повышает качество обслуживания. Согласитесь, приятно знать, что ваш вопрос будет решен именно тем, кто в этом разбирается лучше всего.
3. Саммаризация
Забудьте о длинных цепочках комментариев. ИИ сможет кратко изложить суть обращения, позволяя инженерам быстро понять, что именно требует внимания. Это словно иметь волшебную палочку, которая превращает сложные тексты в ясные и лаконичные отчеты. И теперь у вас больше времени для решения действительно важных задач.
4. Анализ настроений пользователей
Не стоит забывать и об анализе настроений пользователей. ИИ способен уловить тональность обращений клиентов, позволяя технической поддержке быстро реагировать на негативные отзывы. Это значит, что ваша команда всегда будет на шаг впереди, а клиенты — довольны.
5. ИИ для анализа комментариев инженеров по соответствию Tone of Voice компании
И вот мы подходим к финалу нашего путешествия. Как вы думаете, насколько важно анализировать комментарии инженеров на соответствие tone of voice компании? Искусственный интеллект может помочь в этом, оценивая стиль общения сотрудников и обеспечивая единообразие в коммуникации. Это не просто полезно — это необходимо для создания сильного бренда.
👍5🔥3👏3
Forwarded from Железный Человек
Так ли хороша DeepSeek-R1?
Мир сейчас активно обсуждает новую китайскую модель DeepSeek. Команда Cloud․ru не смогла пройти мимо этой темы и решила провести собственное сравнение моделей.
Мы протестировали три модели: OpenAI o1-mini, DeepSeek-R1 и её облегчённую версию DeepSeek-R1 32B. Тестирование проводилось на 40 реальных пользовательских запросах.
Как проходило тестирование:
1️⃣ Для каждого запроса мы использовали систему поиска релевантных статей в документации, которые передавались в модель вместе с пользовательским запросом.
2️⃣ LLM получала системный промпт, требования к Tone of Voice компании, сам вопрос клиента и найденную документацию.
3️⃣ Ответы оценивал эксперт в области технической поддержки по пятибалльной шкале.
Вот, что получилось в результате:
DeepSeek-R1:4.3
OpenAI o1-mini:3.53
DeepSeek-R1 32B:1.75
💡DeepSeek-R1 отлично справляется с задачами, требующими анализа контекста, документации и рассуждений. Облегчённая версия DeepSeek-R1 32B сильно уступает, но её производительность может быть полезной в определённых сценариях.
Какие преимущества DeepSeek-R1 мы выделили:
🔍 В отличие от других популярных моделей, DeepSeek-R1 в обязательном порядке прикладывает настоящие ссылки документации к каждому ответу.
🔍 Эффективно применяет контекст запросов пользователя для генерации более персонализированных ответов.
🔍 Возможность локального развёртывания для обеспечения стабильности, безопасности и автономности.
Я вижу в модели DeepSeek-R1 потенциал. Мы уже начали рассматривать интеграцию модели в сервисы Cloud․ru и запуск нового виртуального ассистента для поддержки наших клиентов. Возможность локального использования — это стратегически важное преимущество, особенно для работы с конфиденциальными данными.
#СверхРазум
Мир сейчас активно обсуждает новую китайскую модель DeepSeek. Команда Cloud․ru не смогла пройти мимо этой темы и решила провести собственное сравнение моделей.
Мы протестировали три модели: OpenAI o1-mini, DeepSeek-R1 и её облегчённую версию DeepSeek-R1 32B. Тестирование проводилось на 40 реальных пользовательских запросах.
Как проходило тестирование:
1️⃣ Для каждого запроса мы использовали систему поиска релевантных статей в документации, которые передавались в модель вместе с пользовательским запросом.
2️⃣ LLM получала системный промпт, требования к Tone of Voice компании, сам вопрос клиента и найденную документацию.
3️⃣ Ответы оценивал эксперт в области технической поддержки по пятибалльной шкале.
Вот, что получилось в результате:
DeepSeek-R1:
OpenAI o1-mini:
DeepSeek-R1 32B:
💡DeepSeek-R1 отлично справляется с задачами, требующими анализа контекста, документации и рассуждений. Облегчённая версия DeepSeek-R1 32B сильно уступает, но её производительность может быть полезной в определённых сценариях.
Какие преимущества DeepSeek-R1 мы выделили:
Я вижу в модели DeepSeek-R1 потенциал. Мы уже начали рассматривать интеграцию модели в сервисы Cloud․ru и запуск нового виртуального ассистента для поддержки наших клиентов. Возможность локального использования — это стратегически важное преимущество, особенно для работы с конфиденциальными данными.
#СверхРазум
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍5❤1
Как ТехПод Google повышает доверие к облачным провайдерам?
Переход на облачные технологии порождает у компаний опасения по поводу утраты контроля над своей инфраструктурой и данными. Эти опасения замедляют процесс миграции в облачные решения, несмотря на преимущества, такие как:
▪️Снижение. затрат Облачные решения позволяют избежать значительных капитальных расходов на оборудование и инфраструктуру.
▪️Масштабируемость. Облачные услуги легко масштабируются в зависимости от потребностей бизнеса.
▪️Безопасность. Многие облачные провайдеры предлагают передовые меры безопасности.
▪️Экспертные инженеры. Облачные провайдеры часто располагают большими командами опытных инженеров и специалистов. Список можно продолжать еще долго.
Многие организации опасаются неопределенности, связанной с облаком. Некоторые даже возвращаются к локальной инфраструктуре, как например сделал Dropbox, покинув AWS.
Каждый из нас инстинктивно боится потерять контроль. И чем выше ставки, тем сильнее тревога. Поэтому неудивительно, что многие организации испытывают страх перед облаком.
Поставщики облачных услуг должны понимать эти опасения и работать над их устранением.
Что предлагает Google? Они создали роль Customer Reliability Engineer(CRE) c учетом их успешного многолетнего опыта Site Reliability Engineering (SRE)
Прежде, чем раскрыть CRE, мы должны узнать, в чем суть SRE?
Представьте себе два враждующих королевства: разработчиков, стремящихся к инновациям, и эксплуатацию, охраняющих стабильность. Каждый из них борется за внимание и признание, но в этой борьбе страдают пользователи. Как же наладить мирное сосуществование?
Революцию принес Бенджамин Трейнор-Слосс с идеей бюджета ошибок. Он осознал, что 100% доступности невозможна, и предложил определить допустимый уровень недоступности. Например, 99,9% означает 43 минуты простоя в месяц — это нормально.
Так родилась новая профессия — инженер по обеспечению надежности объектов (SRE). В Google установилось базовое соглашение между SRE и разработчиками: SRE берет на себя ответственность за бесперебойную работу системы при условии, что:
1️⃣ Система может пройти строгую проверку готовности к производству PRR(Production Readiness Review).
2️⃣ Команда разработчиков согласна поддерживать критически важные системы мониторинга и активно участвовать в ключевых мероприятиях.
3️⃣ Система не превышает своего бюджета ошибок.
Если разработчики не выполняют свои обязательства, SRE могут их «отключить» от прода.
Эти основы сотрудничества создали культуру, способствующую как невероятной надежности, так и быстрому внедрению инноваций.
Согласие на этот бюджет создало новый баланс. Инженеры могут разрабатывать и внедрять новые функции, пока остаются в рамках бюджета. Как только он исчерпан, внимание переключается на стабильность. Это привело к невероятной надежности и стремительному внедрению инноваций.
Теперь этот опыт перенесли на уровень клиентов, и появилась профессия Customer Reliability Engineer (CRE). CRE строит доверительные отношения с клиентами, применяя принципы SRE для их нужд.
Вы не просто обслуживаете клиентов — вы становитесь их надежным партнером, помогая управлять ожиданиями и обеспечивать стабильность. Это новая миссия, создающая крепкие связи и настоящую надежность.
CRE — это то, что вы получаете, когда берете принципы и уроки SRE и применяете их к клиентам.
Команда CRE проверяет ключевые элементы критического приложения/инфраструктуры клиента — код, дизайн, инфраструктуру, операционные процедуры, проводя строгий PRR. В конце указывают на пробелы в надежности системы и дают рекомендации для улучшения.
Создают общую систему мониторинга для синхронизации алертинга и тикетов. Взамен за совместные усилия, клиенты получают:
▪️ Совместный алертинг.
▪️ Автоматическое создание и эскалацию приоритетных заявок.
▪️ Участие CRE в переговорах.
▪️ Систему, одобренную Google.
Сколько это стоит? Продолжение в комментариях
Переход на облачные технологии порождает у компаний опасения по поводу утраты контроля над своей инфраструктурой и данными. Эти опасения замедляют процесс миграции в облачные решения, несмотря на преимущества, такие как:
▪️Снижение. затрат Облачные решения позволяют избежать значительных капитальных расходов на оборудование и инфраструктуру.
▪️Масштабируемость. Облачные услуги легко масштабируются в зависимости от потребностей бизнеса.
▪️Безопасность. Многие облачные провайдеры предлагают передовые меры безопасности.
▪️Экспертные инженеры. Облачные провайдеры часто располагают большими командами опытных инженеров и специалистов. Список можно продолжать еще долго.
Многие организации опасаются неопределенности, связанной с облаком. Некоторые даже возвращаются к локальной инфраструктуре, как например сделал Dropbox, покинув AWS.
Каждый из нас инстинктивно боится потерять контроль. И чем выше ставки, тем сильнее тревога. Поэтому неудивительно, что многие организации испытывают страх перед облаком.
Поставщики облачных услуг должны понимать эти опасения и работать над их устранением.
Что предлагает Google? Они создали роль Customer Reliability Engineer(CRE) c учетом их успешного многолетнего опыта Site Reliability Engineering (SRE)
Прежде, чем раскрыть CRE, мы должны узнать, в чем суть SRE?
Представьте себе два враждующих королевства: разработчиков, стремящихся к инновациям, и эксплуатацию, охраняющих стабильность. Каждый из них борется за внимание и признание, но в этой борьбе страдают пользователи. Как же наладить мирное сосуществование?
Революцию принес Бенджамин Трейнор-Слосс с идеей бюджета ошибок. Он осознал, что 100% доступности невозможна, и предложил определить допустимый уровень недоступности. Например, 99,9% означает 43 минуты простоя в месяц — это нормально.
Так родилась новая профессия — инженер по обеспечению надежности объектов (SRE). В Google установилось базовое соглашение между SRE и разработчиками: SRE берет на себя ответственность за бесперебойную работу системы при условии, что:
1️⃣ Система может пройти строгую проверку готовности к производству PRR(Production Readiness Review).
2️⃣ Команда разработчиков согласна поддерживать критически важные системы мониторинга и активно участвовать в ключевых мероприятиях.
3️⃣ Система не превышает своего бюджета ошибок.
Если разработчики не выполняют свои обязательства, SRE могут их «отключить» от прода.
Эти основы сотрудничества создали культуру, способствующую как невероятной надежности, так и быстрому внедрению инноваций.
Согласие на этот бюджет создало новый баланс. Инженеры могут разрабатывать и внедрять новые функции, пока остаются в рамках бюджета. Как только он исчерпан, внимание переключается на стабильность. Это привело к невероятной надежности и стремительному внедрению инноваций.
Теперь этот опыт перенесли на уровень клиентов, и появилась профессия Customer Reliability Engineer (CRE). CRE строит доверительные отношения с клиентами, применяя принципы SRE для их нужд.
Вы не просто обслуживаете клиентов — вы становитесь их надежным партнером, помогая управлять ожиданиями и обеспечивать стабильность. Это новая миссия, создающая крепкие связи и настоящую надежность.
CRE — это то, что вы получаете, когда берете принципы и уроки SRE и применяете их к клиентам.
Команда CRE проверяет ключевые элементы критического приложения/инфраструктуры клиента — код, дизайн, инфраструктуру, операционные процедуры, проводя строгий PRR. В конце указывают на пробелы в надежности системы и дают рекомендации для улучшения.
Создают общую систему мониторинга для синхронизации алертинга и тикетов. Взамен за совместные усилия, клиенты получают:
▪️ Совместный алертинг.
▪️ Автоматическое создание и эскалацию приоритетных заявок.
▪️ Участие CRE в переговорах.
▪️ Систему, одобренную Google.
Сколько это стоит? Продолжение в комментариях
👍9
Как ИИ превращает техподдержку из «позвать человека» в «спасибо, вы лучшие»?
Время погрузиться в мир практического применения искусственного интеллекта в технической поддержке.
Посмотрите захватывающий доклад: Как мы меняем клиентский сервис с помощью AI [AI&ML]:
Что увидите:
🔥 Как AI-agent работают «по-настоящему» :
▪️ Примеры, когда ИИ не просто отвечает, а решает проблему.
▪️ Почему «сценарный» подход в чат-ботах — это ловушка. И как выйти за их пределы с помощью AI.
🛠️ Секреты масштабирования :
▪️ Как организовать обработку обращений для сотен продуктов без потери качества обслуживания?
🤖 Переход к AI-Агенту
▪️ Не просто чат-бот, а полноценный участник диалога. Он анализирует историю обращений, предлагает решения и даже «улыбается» в ответах .
Почему стоит смотреть?
Потому что это не просто про технологии, а про результаты :
▪️ Как изменились метрики и показатели эффективности после внедрения AI.
▪️ Как инженеры используют простые инструменты — "молнию", "лампочку", "карандаш" и "бумажку" — для улучшения работы.
▪️ Как перейти к AI-Агенту и какие шаги предпринять дальше.
P.S. В конце — секретный бонус: как измерить «дружелюбие» бота и почему это важнее, чем вы думаете.
Время погрузиться в мир практического применения искусственного интеллекта в технической поддержке.
Посмотрите захватывающий доклад: Как мы меняем клиентский сервис с помощью AI [AI&ML]:
Что увидите:
🔥 Как AI-agent работают «по-настоящему» :
▪️ Примеры, когда ИИ не просто отвечает, а решает проблему.
▪️ Почему «сценарный» подход в чат-ботах — это ловушка. И как выйти за их пределы с помощью AI.
🛠️ Секреты масштабирования :
▪️ Как организовать обработку обращений для сотен продуктов без потери качества обслуживания?
🤖 Переход к AI-Агенту
▪️ Не просто чат-бот, а полноценный участник диалога. Он анализирует историю обращений, предлагает решения и даже «улыбается» в ответах .
Почему стоит смотреть?
Потому что это не просто про технологии, а про результаты :
▪️ Как изменились метрики и показатели эффективности после внедрения AI.
▪️ Как инженеры используют простые инструменты — "молнию", "лампочку", "карандаш" и "бумажку" — для улучшения работы.
▪️ Как перейти к AI-Агенту и какие шаги предпринять дальше.
P.S. В конце — секретный бонус: как измерить «дружелюбие» бота и почему это важнее, чем вы думаете.
YouTube
Как мы меняем клиентский сервис с помощью AI [AI&ML]
#GoCloud2025
☁️ Попробуй наше облако бесплатно https://clck.ru/3Ljx6D
Трек: AI&ML
Спикер: Максим Михайлов. Менеджер продукта, Cloud.ru
Обсудим co-pilot и боты в поддержке, новые инструменты, аналитику, будущее Al-агентов и реальные результаты.
☁️ Попробуй наше облако бесплатно https://clck.ru/3Ljx6D
Трек: AI&ML
Спикер: Максим Михайлов. Менеджер продукта, Cloud.ru
Обсудим co-pilot и боты в поддержке, новые инструменты, аналитику, будущее Al-агентов и реальные результаты.
🔥9
Продолжаем исследовать, как AI agent-ы меняют будущее технической поддержки — уже сегодня.
Кейс AstraZeneca
AstraZeneca — глобальная биофармацевтическая компания с выручкой более $27 млрд в год , которая делает ставку на искусственный интеллект, облачные технологии и кибербезопасность.
Мне нравится их лозунг — «Every minute matters» . Красиво звучит, особенно в медицине.
А теперь — сам кейс:
Cотрудник получает уведомление об отключении оборудования. Он звонит AI agent-у и рассказывает, что видит ошибку на экране.
1️⃣ AI просит прислать фото — и начинает действовать: Анализирует изображение и определяет тип повреждения
2️⃣ Проверяет гарантийный статус устройства
3️⃣ Инициирует замену
4️⃣ Организует закупку нового оборудования и отправляет номер заказа для отслеживания
Это. Очень. Круто.
Но вот что ещё круче:
С помощью AI agent-ов компания сократила время обработки запроса на поставку оборудования с 20–30 минут до нескольких секунд .
Это звучит особенно впечатляюще, если понимать масштаб:
У AstraZeneca ежегодно возникает около 60 000 таких запросов , что ранее занимало примерно 90 000 человеко-часов .
Теперь эти часы можно направить на действительно важную работу.
Будущее техподдержки — это когда ИИ берёт рутину, а люди — результат.
#кейс #ТехническаяПоддержка #AI
Кейс AstraZeneca
AstraZeneca — глобальная биофармацевтическая компания с выручкой более $27 млрд в год , которая делает ставку на искусственный интеллект, облачные технологии и кибербезопасность.
Мне нравится их лозунг — «Every minute matters» . Красиво звучит, особенно в медицине.
А теперь — сам кейс:
Cотрудник получает уведомление об отключении оборудования. Он звонит AI agent-у и рассказывает, что видит ошибку на экране.
Это. Очень. Круто.
Но вот что ещё круче:
С помощью AI agent-ов компания сократила время обработки запроса на поставку оборудования с 20–30 минут до нескольких секунд .
Это звучит особенно впечатляюще, если понимать масштаб:
У AstraZeneca ежегодно возникает около 60 000 таких запросов , что ранее занимало примерно 90 000 человеко-часов .
Теперь эти часы можно направить на действительно важную работу.
Будущее техподдержки — это когда ИИ берёт рутину, а люди — результат.
#кейс #ТехническаяПоддержка #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥2
Что такое Hypercare?
Hypercare — это период усиленной поддержки сразу после запуска нового продукта.
Клиенты только начинают осваивать интерфейс, разбираться с функциями, адаптировать процессы.
Усиленная поддержка работает до тех пор, пока всё не станет стабильно.
Представь: компания — как скорая помощь.
Быстро реагируем, помогаем разобраться с проблемами и показываем, что заботимся о пользователе.
🚀 Почему Hypercare особенно важен при выходе нового продукта?
Запуск — всегда стресс. Не только для команды, но и для клиентов.
Они боятся:
▪️Сложностей освоения
▪️Ошибок и простоев
▪️Потери привычного функционала
Hypercare позволяет:
▪️Успокоить клиентов
▪️Быстро решать проблемы
▪️Обеспечить плавный переход
▪️Превратить стресс в доверие
▪️Контролировать качество сервиса
▪️Убедиться, что решение работает как задумывалось
▪️Проверить, что команда готова к своим обязанностям
⚠️ Что будет, если пропустить Hypercare?
Как сесть в лодку без весел:
▪️Критические баги могут остаться незамеченными
▪️Пользователи не поймут, как работать с решением
▪️Репутация продукта пострадает
▪️Мелкие проблемы станут большими
🛠 Как организовать Hypercare при запуске нового продукта
Шаг 1. Сформируйте команду
Создайте специальную группу для поддержки продукта:
▪️L1, L2, L3
▪️Менеджеры БЗ
▪️Аналитики
Шаг 2. Обучите команду
Подготовьте персонал к работе:
▪️Изучение интерфейса и функций
▪️Отработка типовых вопросов
▪️Администрирование
▪️Эскалационная схема
▪️Настройка алертов
Шаг 3. Коммуницируйте заранее
До запуска объясните пользователям:
▪️Что меняется
▪️Зачем это нужно
▪️Как получить помощь
▪️Где найти инструкции и обучающие материалы
Шаг 4. Мониторьте показатели
Фокусируйтесь на метриках:
▪️Скорость ответа и закрытия обращений
▪️Темы обращений
▪️Отклонения от нормальных значений
Шаг 5. Собирайте обратную связь
Используйте:
▪️ Опросы
▪️ Формы
▪️ Прямую коммуникацию
Чтобы улучшить следующий запуск и сам продукт.
❌ Частые ошибки при запуске без Hypercare
1. Выгорание команды
Резкий рост обращений истощает сотрудников.
2. Неподготовленность команды
Без чёткого плана действия хаотичны.
3. Неправильная приоритизация запросов
Мелкие вопросы затмевают настоящие проблемы.
4. Разнобой в ответах
Если каждый говорит по-своему — клиент теряет доверие.
✅ Преимущества Hypercare при запуске нового продукта
1. Увеличение удовлетворённости (CSAT)
Клиенты получают быструю и качественную поддержку через удобные каналы. Это создаёт ощущение, что их услышали и ценят.
2. Снижение оттока (churn)
Когда видишь, что тебя поддерживают — остаёшься. Особенно в момент неопределённости.
3. Рост adoption
Пользователи активно используют продукт, когда чувствуют уверенность.
А она даётся грамотной поддержкой и обучением в первые недели.
> Когда ваша команда объясняет, как работают новые фичи — клиенты не просто используют продукт. Они полюбят его.
❓Часто задаваемые вопросы
Сколько длится Hypercare?
Обычно — 2–4 недели. Время зависит от сложности продукта и реакции пользователей.
Что дальше?
Начинается этап пост-гоу-лайв поддержки.
Нет повышенной нагрузки, но важно сохранять высокий уровень обслуживания и продолжать собирать обратную связь для будущих улучшений.
🎯 Итог
Hypercare — не прихоть, а необходимость.
Это время, когда формируется первое впечатление о продукте, закладывается его репутация и создаётся база для успешного будущего.
Пренебрегать Hypercare — всё равно что запустить ракету, но не проверить систему посадки.
Взлёт прошёл успешно, а вот с приземлением могут возникнуть проблемы.
Хочешь надёжный запуск?
Делай Hypercare. И делай его правильно.
#Hypercare #TechSupport #IT #ProductLaunch #CustomerSuccess #SupportTeam
Hypercare — это период усиленной поддержки сразу после запуска нового продукта.
Клиенты только начинают осваивать интерфейс, разбираться с функциями, адаптировать процессы.
Усиленная поддержка работает до тех пор, пока всё не станет стабильно.
Представь: компания — как скорая помощь.
Быстро реагируем, помогаем разобраться с проблемами и показываем, что заботимся о пользователе.
Запуск — всегда стресс. Не только для команды, но и для клиентов.
Они боятся:
▪️Сложностей освоения
▪️Ошибок и простоев
▪️Потери привычного функционала
Hypercare позволяет:
▪️Успокоить клиентов
▪️Быстро решать проблемы
▪️Обеспечить плавный переход
▪️Превратить стресс в доверие
▪️Контролировать качество сервиса
▪️Убедиться, что решение работает как задумывалось
▪️Проверить, что команда готова к своим обязанностям
⚠️ Что будет, если пропустить Hypercare?
Как сесть в лодку без весел:
▪️Критические баги могут остаться незамеченными
▪️Пользователи не поймут, как работать с решением
▪️Репутация продукта пострадает
▪️Мелкие проблемы станут большими
🛠 Как организовать Hypercare при запуске нового продукта
Шаг 1. Сформируйте команду
Создайте специальную группу для поддержки продукта:
▪️L1, L2, L3
▪️Менеджеры БЗ
▪️Аналитики
Шаг 2. Обучите команду
Подготовьте персонал к работе:
▪️Изучение интерфейса и функций
▪️Отработка типовых вопросов
▪️Администрирование
▪️Эскалационная схема
▪️Настройка алертов
Шаг 3. Коммуницируйте заранее
До запуска объясните пользователям:
▪️Что меняется
▪️Зачем это нужно
▪️Как получить помощь
▪️Где найти инструкции и обучающие материалы
Шаг 4. Мониторьте показатели
Фокусируйтесь на метриках:
▪️Скорость ответа и закрытия обращений
▪️Темы обращений
▪️Отклонения от нормальных значений
Шаг 5. Собирайте обратную связь
Используйте:
▪️ Опросы
▪️ Формы
▪️ Прямую коммуникацию
Чтобы улучшить следующий запуск и сам продукт.
❌ Частые ошибки при запуске без Hypercare
1. Выгорание команды
Резкий рост обращений истощает сотрудников.
2. Неподготовленность команды
Без чёткого плана действия хаотичны.
3. Неправильная приоритизация запросов
Мелкие вопросы затмевают настоящие проблемы.
4. Разнобой в ответах
Если каждый говорит по-своему — клиент теряет доверие.
✅ Преимущества Hypercare при запуске нового продукта
1. Увеличение удовлетворённости (CSAT)
Клиенты получают быструю и качественную поддержку через удобные каналы. Это создаёт ощущение, что их услышали и ценят.
2. Снижение оттока (churn)
Когда видишь, что тебя поддерживают — остаёшься. Особенно в момент неопределённости.
3. Рост adoption
Пользователи активно используют продукт, когда чувствуют уверенность.
А она даётся грамотной поддержкой и обучением в первые недели.
> Когда ваша команда объясняет, как работают новые фичи — клиенты не просто используют продукт. Они полюбят его.
❓Часто задаваемые вопросы
Сколько длится Hypercare?
Обычно — 2–4 недели. Время зависит от сложности продукта и реакции пользователей.
Что дальше?
Начинается этап пост-гоу-лайв поддержки.
Нет повышенной нагрузки, но важно сохранять высокий уровень обслуживания и продолжать собирать обратную связь для будущих улучшений.
🎯 Итог
Hypercare — не прихоть, а необходимость.
Это время, когда формируется первое впечатление о продукте, закладывается его репутация и создаётся база для успешного будущего.
Пренебрегать Hypercare — всё равно что запустить ракету, но не проверить систему посадки.
Взлёт прошёл успешно, а вот с приземлением могут возникнуть проблемы.
Хочешь надёжный запуск?
Делай Hypercare. И делай его правильно.
#Hypercare #TechSupport #IT #ProductLaunch #CustomerSuccess #SupportTeam
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11
Прочитал книгу Real ITSM: Проверено временем от Cleverics. Все главы также также доступны у них на сайте.
Какие мысли понравились:
Мысль 1: Люди важнее процессов. Или почему ITIL не работает без культуры
Есть одна старая мудрость:
Это сказал Роб Ингланд. Один из самых уважаемых голосов в ITSM.
И вот что важно: большинство ITSM-проектов заканчиваются внедрением инструментов или документации. Но настоящий успех приходит только тогда, когда меняется поведение людей.
Ты можешь написать идеальные SLA, внедрить AI и автоматизировать Incident Management.
Но если никто не понимает, зачем это делается — процессы останутся бумагой. А команда будет работать так, как привыкла.
В этом фундаментальная проблема многих проектов: мы меняем систему, но забываем про культуру.
Если ты руководишь — твоя задача не запустить процесс. Твоя задача — создать условия, где он будет жить, развиваться и помогать людям делать лучше.
Потому что технологии работают только тогда, когда за ними работают люди.
Мысль 2: Управление проблемами — ключ к скорости
Вы замечали: одни и те же инциденты возникают снова и снова?
Типичный ответ техподдержки:
Но если проблема остаётся — она будет стоить вам больше времени, больше нервов и больше денег .
🔍 Управление проблемами — это не про реакцию. Это про профилактику.
Когда инженер второй линии решает один и тот же инцидент по 20 раз в месяц, он тратит часы на то, что можно было бы решить один раз, но глубоко .
⚙️ Как это работает:
1️⃣ Фиксируется повторяющийся инцидент
2️⃣ Создаётся проблема
3️⃣ Диагностируется корень
4️⃣ Разрабатывается обходное решение или исправление
5️⃣ Информация передаётся в Change Management
Это не просто работа с ошибками. Это работа над тем, чтобы этих ошибок становилось меньше.
Мысль 3: 🎯 Метрики без целей — это шум
Метрики нужны, чтобы видеть картину.
Но они должны отвечать на вопросы:
1️⃣ Как мы улучшаем опыт клиента?
2️⃣ Что работает хорошо, а что требует корректировки?
3️⃣ Какие точки в процессе тормозят команду?
Если метрика не помогает ответить на эти вопросы — она бесполезна.
Даже если она красиво оформлена в дашборде.
#ITIL #Метрики
Какие мысли понравились:
Мысль 1: Люди важнее процессов. Или почему ITIL не работает без культуры
Есть одна старая мудрость:
Хорошие люди могут работать с плохими процессами.
Хорошие процессы могут компенсировать плохое ПО.
Но лучшее ПО не спасёт плохие процессы.
А лучшие процессы — не создадут хороших людей.
Это сказал Роб Ингланд. Один из самых уважаемых голосов в ITSM.
И вот что важно: большинство ITSM-проектов заканчиваются внедрением инструментов или документации. Но настоящий успех приходит только тогда, когда меняется поведение людей.
Ты можешь написать идеальные SLA, внедрить AI и автоматизировать Incident Management.
Но если никто не понимает, зачем это делается — процессы останутся бумагой. А команда будет работать так, как привыкла.
В этом фундаментальная проблема многих проектов: мы меняем систему, но забываем про культуру.
Если ты руководишь — твоя задача не запустить процесс. Твоя задача — создать условия, где он будет жить, развиваться и помогать людям делать лучше.
Потому что технологии работают только тогда, когда за ними работают люди.
Мысль 2: Управление проблемами — ключ к скорости
Вы замечали: одни и те же инциденты возникают снова и снова?
Типичный ответ техподдержки:
«Я закрыл обращение. SLA соблюдено. Все довольны».
Но если проблема остаётся — она будет стоить вам больше времени, больше нервов и больше денег .
🔍 Управление проблемами — это не про реакцию. Это про профилактику.
Когда инженер второй линии решает один и тот же инцидент по 20 раз в месяц, он тратит часы на то, что можно было бы решить один раз, но глубоко .
⚙️ Как это работает:
Это не просто работа с ошибками. Это работа над тем, чтобы этих ошибок становилось меньше.
Мысль 3: 🎯 Метрики без целей — это шум
Метрики нужны, чтобы видеть картину.
Но они должны отвечать на вопросы:
Если метрика не помогает ответить на эти вопросы — она бесполезна.
Даже если она красиво оформлена в дашборде.
#ITIL #Метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤🔥2✍1❤1
Что такое Incident Management? Часть 1/2
Incident Management - это управление жизненным циклом инцидента, от первого сигнала до полного восстановления сервиса.
Цель - не просто закрыть заявку.
Цель - восстановить нормальную работу как можно быстрее, с минимальным влиянием на клиентов и бизнес.
Что такое инцидент?
Инцидент - это любое событие, которое нарушает нормальную работу сервиса.
Это не обязательно «всё упало».
Это может быть:
▪️ пользователь не может войти в систему,
▪️ сервис работает медленно,
▪️ кто-то увидел ошибку в логах и напугался,
▪️ или просто: «Я не понимаю, что происходит».
Главное - влияние на пользователя.
Основные цели Incident Management
1️⃣ Восстановить сервис как можно быстрее
Не обязательно найти корневую причину.
Достаточно вернуть работоспособность - даже временным решением.
2️⃣ Минимизировать влияние на бизнес
Чем дольше сервис недоступен - тем больше ущерб.
3️⃣ Соблюдать стандарты и SLA
Это не бюрократия.
Это обещание, которое вы даёте клиенту.
5️⃣ Передать проблему дальше, если нужно
Инцидент - это симптом.
А значит, за ним может быть проблема, которую нужно изучить.
Кто участвует?
1️⃣ L1(1-ая линия)
Это фронт.
Их задача - не решить всё, а:
▪️ зарегистрировать инцидент,
▪️ определить приоритет,
▪️ передать в нужную группу,
▪️ держать клиента в курсе.
2️⃣ IT Support Team (вторая и третья линия)
Это эксперты.
У них глубокие знания по конкретным сервисам.
Они:
▪️ диагностируют,
▪️ ищут корень,
▪️ создают обходные решения,
▪️ инициируют изменения.
Те, кто делает сервис снова рабочим.
3️⃣ Incident Manager (менеджер процесса)
Не каждый инцидент требует менеджера.
Но если инцидент критичный - он появляется.
Его задача:
▪️ координировать,
▪️ следить за SLA,
▪️ информировать бизнес,
▪️ и не давать процессу выйти из-под контроля.
Он - дирижёр, а не музыкант
Как начинается инцидент?
Инцидент может начаться:
▪️ от пользователя («не работает»),
▪️ от мониторинга («сервер не отвечает»),
▪️ от внутренней команды («заметили аномалию»).
🔄 Жизненный цикл инцидента: от «сломалось» до «всё снова работает»
Каждый инцидент проходит через четыре ключевые фазы:
1️⃣ Регистрация
Инцидент поступает - через портал, чат, телефон.
Его нужно: зарегистрировать, присвоить ID, указать категорию и приоритет.
2️⃣ Диагностика и расследование
Что не работает?
Где?
Кто ответственный/может помочь?
Нужна ли эскалация?
3️⃣ Решение и восстановление
Найден обходной путь?
Устранена ошибка?
Сервис восстановлен?
5️⃣ Закрытие и анализ
Клиент подтвердил?
Есть ли риск повтора?
Нужно ли передать в Problem Management?
🔥 Срочность и влияние: как определить, что срочно, а что — критично
Не все инциденты одинаковы.
Именно поэтому в Incident Management есть два ключевых параметра:
Влияние (Impact)
Кто и что пострадало?
Насколько широко проблема затрагивает бизнес?
Высокое - сервис недоступен для большого числа пользователей или критичных подразделений.
Среднее - несколько пользователей или одно подразделение.
Низкое - один пользователь, не критичная функция.
⏱Срочность (Urgency)
Насколько быстро нужно решить?
Высокая - требует немедленного вмешательства, например, остановка бизнес-процесса
Средняя - важно, но можно подождать несколько часов
Низкая - стандартный запрос, срок решения - дни
Из этих двух параметров формируется приоритет инцидента.
Приоритет = Влияние × Срочность
Зачем это нужно?
Чтобы:
▪️ не терять время на низкоприоритетные задачи, пока горит критичный сервис,
▪️ правильно распределять нагрузку,
▪️ соблюдать SLA,
▪️ и главное - говорить с бизнесом на одном языке.
«срочно» и «важно» - это не одно и то же.
Во второй части поговорим о Major Incident, метриках и связи с другими процессами.
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка
Incident Management - это управление жизненным циклом инцидента, от первого сигнала до полного восстановления сервиса.
Цель - не просто закрыть заявку.
Цель - восстановить нормальную работу как можно быстрее, с минимальным влиянием на клиентов и бизнес.
Что такое инцидент?
Инцидент - это любое событие, которое нарушает нормальную работу сервиса.
Это не обязательно «всё упало».
Это может быть:
▪️ пользователь не может войти в систему,
▪️ сервис работает медленно,
▪️ кто-то увидел ошибку в логах и напугался,
▪️ или просто: «Я не понимаю, что происходит».
Главное - влияние на пользователя.
Основные цели Incident Management
Не обязательно найти корневую причину.
Достаточно вернуть работоспособность - даже временным решением.
Чем дольше сервис недоступен - тем больше ущерб.
Это не бюрократия.
Это обещание, которое вы даёте клиенту.
Инцидент - это симптом.
А значит, за ним может быть проблема, которую нужно изучить.
Кто участвует?
Это фронт.
Их задача - не решить всё, а:
▪️ зарегистрировать инцидент,
▪️ определить приоритет,
▪️ передать в нужную группу,
▪️ держать клиента в курсе.
Это эксперты.
У них глубокие знания по конкретным сервисам.
Они:
▪️ диагностируют,
▪️ ищут корень,
▪️ создают обходные решения,
▪️ инициируют изменения.
Те, кто делает сервис снова рабочим.
Не каждый инцидент требует менеджера.
Но если инцидент критичный - он появляется.
Его задача:
▪️ координировать,
▪️ следить за SLA,
▪️ информировать бизнес,
▪️ и не давать процессу выйти из-под контроля.
Он - дирижёр, а не музыкант
Как начинается инцидент?
Инцидент может начаться:
▪️ от пользователя («не работает»),
▪️ от мониторинга («сервер не отвечает»),
▪️ от внутренней команды («заметили аномалию»).
🔄 Жизненный цикл инцидента: от «сломалось» до «всё снова работает»
Каждый инцидент проходит через четыре ключевые фазы:
Инцидент поступает - через портал, чат, телефон.
Его нужно: зарегистрировать, присвоить ID, указать категорию и приоритет.
Что не работает?
Где?
Кто ответственный/может помочь?
Нужна ли эскалация?
Найден обходной путь?
Устранена ошибка?
Сервис восстановлен?
Клиент подтвердил?
Есть ли риск повтора?
Нужно ли передать в Problem Management?
🔥 Срочность и влияние: как определить, что срочно, а что — критично
Не все инциденты одинаковы.
Именно поэтому в Incident Management есть два ключевых параметра:
Влияние (Impact)
Кто и что пострадало?
Насколько широко проблема затрагивает бизнес?
Высокое - сервис недоступен для большого числа пользователей или критичных подразделений.
Среднее - несколько пользователей или одно подразделение.
Низкое - один пользователь, не критичная функция.
⏱Срочность (Urgency)
Насколько быстро нужно решить?
Высокая - требует немедленного вмешательства, например, остановка бизнес-процесса
Средняя - важно, но можно подождать несколько часов
Низкая - стандартный запрос, срок решения - дни
Из этих двух параметров формируется приоритет инцидента.
Приоритет = Влияние × Срочность
Зачем это нужно?
Чтобы:
▪️ не терять время на низкоприоритетные задачи, пока горит критичный сервис,
▪️ правильно распределять нагрузку,
▪️ соблюдать SLA,
▪️ и главное - говорить с бизнесом на одном языке.
«срочно» и «важно» - это не одно и то же.
Во второй части поговорим о Major Incident, метриках и связи с другими процессами.
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍3
Что такое Incident Management? Часть 2/2
🚨 Major Incident: когда всё пошло не так
Major Incident - это не просто «очень плохой» инцидент.
Это событие, которое лишает бизнес критичной услуги.
▪️ Много пользователей не могут работать.
▪️ Сервис остановлен.
▪️ Финансовые потери растут.
▪️ Появляется давление сверху.
В таких случаях включается отдельная процедура:
▪️ Назначается менеджер Major Incident (лучше - менеджер процесса, а не техник).
▪️ Собирается команда из нескольких групп.
▪️ Включается режим постоянного информирования.
▪️ Все обращения от пользователей связываются с основным инцидентом.
На что опирается Incident Management?
Это не изолированный процесс.
Он живёт за счёт других:
▪️ Configuration Management - карта сервисов и их зависимостей - чтобы понять, кто пострадал.
▪️ Problem Management - чтобы найти корневую причин, а не просто лечить симптомы.
▪️ Change Management - понимание, не было ли изменения причиной инцидента.
▪️ Knowledge Management - готовые решения, которые можно применить сразу.
▪️ Service Level Management - чтобы знать, что обещано клиенту.
Без этих процессов - Incident Management превращается в бег по кругу.
Хороший инцидент - это тот, который уже был решён раньше.
📊 Метрики: что измерять?
Не ради отчётов. Они - чтобы видеть, где ты теряешь контроль.
▪️ FCR (First Contact Resolution) - Сколько инцидентов решено с первого раза
▪️ TTR (Time to Resolve) - Среднее время решения
▪️ SLA Breach % Сколько инцидентов вышло за срок
▪️ Escalation Rate - Сколько инцидентов ушло на вторую линию
▪️ CSAT - Удовлетворённость клиента
Итог
Incident Management - это не просто реакция.
Это система, которая:
▪️ восстанавливает сервис,
▪️ восстанавливает доверие,
▪️ учится на ошибках,
▪️ и делает так, чтобы их было меньше.
Если у вас нет Incident Management - вы не управляете.
Вы просто тушите пожары.
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка
🚨 Major Incident: когда всё пошло не так
Major Incident - это не просто «очень плохой» инцидент.
Это событие, которое лишает бизнес критичной услуги.
▪️ Много пользователей не могут работать.
▪️ Сервис остановлен.
▪️ Финансовые потери растут.
▪️ Появляется давление сверху.
В таких случаях включается отдельная процедура:
▪️ Назначается менеджер Major Incident (лучше - менеджер процесса, а не техник).
▪️ Собирается команда из нескольких групп.
▪️ Включается режим постоянного информирования.
▪️ Все обращения от пользователей связываются с основным инцидентом.
На что опирается Incident Management?
Это не изолированный процесс.
Он живёт за счёт других:
▪️ Configuration Management - карта сервисов и их зависимостей - чтобы понять, кто пострадал.
▪️ Problem Management - чтобы найти корневую причин, а не просто лечить симптомы.
▪️ Change Management - понимание, не было ли изменения причиной инцидента.
▪️ Knowledge Management - готовые решения, которые можно применить сразу.
▪️ Service Level Management - чтобы знать, что обещано клиенту.
Без этих процессов - Incident Management превращается в бег по кругу.
Хороший инцидент - это тот, который уже был решён раньше.
📊 Метрики: что измерять?
Не ради отчётов. Они - чтобы видеть, где ты теряешь контроль.
▪️ FCR (First Contact Resolution) - Сколько инцидентов решено с первого раза
▪️ TTR (Time to Resolve) - Среднее время решения
▪️ SLA Breach % Сколько инцидентов вышло за срок
▪️ Escalation Rate - Сколько инцидентов ушло на вторую линию
▪️ CSAT - Удовлетворённость клиента
Итог
Incident Management - это не просто реакция.
Это система, которая:
▪️ восстанавливает сервис,
▪️ восстанавливает доверие,
▪️ учится на ошибках,
▪️ и делает так, чтобы их было меньше.
Если у вас нет Incident Management - вы не управляете.
Вы просто тушите пожары.
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка
🔥8👍2✍1
The State of Tech support 2025.pdf
781.4 KB
Исследование HDI The State of Tech support 2025
HDI опросил 115 лидеров отрасли. Вот что показал отчёт.
1. Технологии меняются быстрее, чем мы успеваем учиться
▪️ 54% компаний говорят: обучение стало сложнее за последние 3 года.
▪️ 67% - проблема не в людях, а в информационной перегрузке.
▪️ 34% видят рост числа тикетов. Средний объём - 10 675 заявок в месяц.
▪️ 45% чувствуют, что отстают в освоении новых инструментов.
Технологии опережают подготовку. Поддержка бежит в гору, но с рюкзаком из устаревших процессов.
2. Жёсткие навыки важны. Но мягкие - решают
▪️ 55% - главная проблема найма: не хватает soft skills.
▪️ Только 39% жалуются на нехватку hard skills.
▪️ Теперь важно не только знать, но и объяснить, выслушать, поддержать.
▪️ Критическое мышление, эмпатия, умение работать в команде - стали must-have.
▪️ И найти человека с этим балансом - тяжелее, чем сдать экзамен по CCNA.
3. AI - не угроза. Это шанс перестроиться
▪️ 71% вкладывают в технологии ради лучшего опыта клиента.
▪️ 42% считают, что ИИ будет играть ключевую роль в обучении.
▪️ 14% уже используют ИИ в тренировках, 38% - готовятся к внедрению.
Да, 50% ожидают, что некоторые позиции станут ненужными.
Но другие - появятся. Главное - не сопротивляться, а переквалифицироваться.
4. Экономика давит
▪️ В 2024 повышения получили 56% сотрудников.
В 2025 - ожидает только 42%.
▪️ 46% чувствуют себя недооценёнными.
▪️ 12-13% ждут сокращения льгот (в 2024 - 5-7%).
▪️ 30% сомневаются, что найдут такую же работу, если уволят.
▪️ 15% ожидают заморозки найма.
Но есть и свет: 45%, кто пытался договориться о зарплате - получили.
5. Уважение - это не бонус. Это основа
▪️ 75% команд столкнулись с высокой текучкой
▪️ 59% отметили: это влияет на сервис и на продуктивность.
Что работает:
▪️ Честная оплата - подтверждает ценность.
▪️ Баланс - уважает личное время.
▪️ Карьерные пути - показывают: ты не расходный материал.
▪️ Признание - напоминает: тебя видят.
«Уважение - это инвестиция. И оно окупается стабильностью, качеством и лояльностью» - Томас HDI.
Нашел в канале Клиентский опыт и качество
#Исследования #Тренды
HDI опросил 115 лидеров отрасли. Вот что показал отчёт.
1. Технологии меняются быстрее, чем мы успеваем учиться
▪️ 54% компаний говорят: обучение стало сложнее за последние 3 года.
▪️ 67% - проблема не в людях, а в информационной перегрузке.
▪️ 34% видят рост числа тикетов. Средний объём - 10 675 заявок в месяц.
▪️ 45% чувствуют, что отстают в освоении новых инструментов.
Технологии опережают подготовку. Поддержка бежит в гору, но с рюкзаком из устаревших процессов.
2. Жёсткие навыки важны. Но мягкие - решают
▪️ 55% - главная проблема найма: не хватает soft skills.
▪️ Только 39% жалуются на нехватку hard skills.
▪️ Теперь важно не только знать, но и объяснить, выслушать, поддержать.
▪️ Критическое мышление, эмпатия, умение работать в команде - стали must-have.
▪️ И найти человека с этим балансом - тяжелее, чем сдать экзамен по CCNA.
3. AI - не угроза. Это шанс перестроиться
▪️ 71% вкладывают в технологии ради лучшего опыта клиента.
▪️ 42% считают, что ИИ будет играть ключевую роль в обучении.
▪️ 14% уже используют ИИ в тренировках, 38% - готовятся к внедрению.
Да, 50% ожидают, что некоторые позиции станут ненужными.
Но другие - появятся. Главное - не сопротивляться, а переквалифицироваться.
4. Экономика давит
▪️ В 2024 повышения получили 56% сотрудников.
В 2025 - ожидает только 42%.
▪️ 46% чувствуют себя недооценёнными.
▪️ 12-13% ждут сокращения льгот (в 2024 - 5-7%).
▪️ 30% сомневаются, что найдут такую же работу, если уволят.
▪️ 15% ожидают заморозки найма.
Но есть и свет: 45%, кто пытался договориться о зарплате - получили.
5. Уважение - это не бонус. Это основа
▪️ 75% команд столкнулись с высокой текучкой
▪️ 59% отметили: это влияет на сервис и на продуктивность.
Что работает:
▪️ Честная оплата - подтверждает ценность.
▪️ Баланс - уважает личное время.
▪️ Карьерные пути - показывают: ты не расходный материал.
▪️ Признание - напоминает: тебя видят.
«Уважение - это инвестиция. И оно окупается стабильностью, качеством и лояльностью» - Томас HDI.
Нашел в канале Клиентский опыт и качество
#Исследования #Тренды
👍7🔥3❤2
Problem Management.
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину, по которой он сломался.
Если инцидент - это симптом, то проблема - это источник боли.
Что такое проблема?
Проблема - это неизвестная корневая причина одного или нескольких инцидентов.
Примеры:
▪️ У 15 клиентов за день упал один и тот же сервис.
▪️ Сервер каждый понедельник в 9:00 замедляется на 30 минут.
▪️ После каждого обновления падает интеграция с биллингом.
Инцидент - это «не могу войти».
Проблема - это «почему у 200 пользователей каждый четверг в 14:00 падает авторизация».
Что такое Problem Management?
Это процесс поиска и устранения корневых причин инцидентов.
Не чтобы закрыть тикет. А чтобы больше не открывать такие тикеты.
Цель - не реагировать. Цель - предотвратить.
Основные цели Problem Management
1️⃣ Найти корневую причину
Не «починили» - а поняли, почему сломалось.
2️⃣ Предотвратить повторение
Устранить не симптом, а источник.
Чтобы инцидент больше не возникал.
3️⃣ Создать долгосрочное решение
Не временный обходной путь, а постоянное исправление - в коде, в архитектуре, в процессе.
5️⃣ Связать инциденты в паттерны*
Увидеть, что 10 разных инцидентов — на самом деле одна проблема.
5️⃣ Передать знания команде
Зафиксировать решение в базе знаний.
Чтобы следующий инженер не изобретал велосипед.
Когда запускается Problem Management?
Проблема может начаться:
▪️ после серии повторяющихся инцидентов,
▪️ после Major Incident (там всегда есть корень),
▪️ по инициативе инженера: «Я вижу закономерность»,
▪️ из аналитики: «Сервис падает каждый раз после бэкапа».
Главное - не ждать. Если инцидент повторяется - пора искать проблему.
Как работает процесс?
1️⃣ Выявление проблемы
▪️ Анализ инцидентов.
▪️ Выявление паттернов.
▪️ Сигнал: «Никогда такого не было. И вот опять».
2️⃣ Корневой анализ (RCA)
▪️ Не «что упало», а «почему упало».
▪️ Методы: 5 Why, Fishbone, Timeline Analysis.
▪️ Важно: искать системную причину, а не виноватого.
3️⃣ Поиск постоянного решения
▪️ Это не обходное решение.
▪️ Это изменение: в коде, архитектуре, процессе, документации.
5️⃣ Реализация через Change Management
▪️ Никаких «сделал и забыл».
▪️ Решение внедряется официально, с тестированием и апрувами.
5️⃣ Закрытие и артефакт
▪️ Клиент доволен?
▪️ Инциденты прекратились?
▪️ Значит, проблема решена.
▪️ И артефакт (документ, статья, чек-лист) — сохранён для команды.
Кто участвует?
▪️ Problem Manager - не техник, а аналитик.
Он видит систему, а не только симптомы.
▪️ L2/L3, SRE, DevOps, разработка - те, кто может глубоко копать.
▪️ Incident Manager - передаёт контекст: что, где, сколько раз.
▪️ Knowledge Manager - фиксирует решение, чтобы оно не потерялось.
Зачем это измерять?
Потому что:
▪️ Сколько проблем выявлено и закрыто?
Если ноль — значит, вы не смотрите.
▪️ Среднее время на решение проблемы
Не торопитесь. Главное — качество анализа.
▪️ Снижение количества инцидентов после решения
Это и есть доказательство эффективности.
▪️ Доля инцидентов, связанных с известными проблемами
Если высокая - у вас есть «дыра», которую давно пора закрыть.
Типичные ошибки
▪️ Не начинают вовремя
Ждут, пока станет «очень плохо».
▪️ Смешивают с Incident Management.
Инженер пытается «починить и разобраться» одновременно.
Не получается.
▪️ Не фиксируют артефакты.
Решение «в голове» - это не решение.
Это риск.
▪️ Не передают в Change Management.
«Поправили вручную» - и снова ждут, пока упадёт.
Итог
Incident Management - это пожарная команда
Problem Management - это инженер, который проверяет проводку.
Хороший процесс - это когда пожаров становится всё меньше.
#ProblemManagement #ITIL #TechSupport
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину, по которой он сломался.
Если инцидент - это симптом, то проблема - это источник боли.
Что такое проблема?
Проблема - это неизвестная корневая причина одного или нескольких инцидентов.
Примеры:
▪️ У 15 клиентов за день упал один и тот же сервис.
▪️ Сервер каждый понедельник в 9:00 замедляется на 30 минут.
▪️ После каждого обновления падает интеграция с биллингом.
Инцидент - это «не могу войти».
Проблема - это «почему у 200 пользователей каждый четверг в 14:00 падает авторизация».
Что такое Problem Management?
Это процесс поиска и устранения корневых причин инцидентов.
Не чтобы закрыть тикет. А чтобы больше не открывать такие тикеты.
Цель - не реагировать. Цель - предотвратить.
Основные цели Problem Management
Не «починили» - а поняли, почему сломалось.
Устранить не симптом, а источник.
Чтобы инцидент больше не возникал.
Не временный обходной путь, а постоянное исправление - в коде, в архитектуре, в процессе.
Увидеть, что 10 разных инцидентов — на самом деле одна проблема.
Зафиксировать решение в базе знаний.
Чтобы следующий инженер не изобретал велосипед.
Когда запускается Problem Management?
Проблема может начаться:
▪️ после серии повторяющихся инцидентов,
▪️ после Major Incident (там всегда есть корень),
▪️ по инициативе инженера: «Я вижу закономерность»,
▪️ из аналитики: «Сервис падает каждый раз после бэкапа».
Главное - не ждать. Если инцидент повторяется - пора искать проблему.
Как работает процесс?
▪️ Анализ инцидентов.
▪️ Выявление паттернов.
▪️ Сигнал: «Никогда такого не было. И вот опять».
▪️ Не «что упало», а «почему упало».
▪️ Методы: 5 Why, Fishbone, Timeline Analysis.
▪️ Важно: искать системную причину, а не виноватого.
▪️ Это не обходное решение.
▪️ Это изменение: в коде, архитектуре, процессе, документации.
▪️ Никаких «сделал и забыл».
▪️ Решение внедряется официально, с тестированием и апрувами.
▪️ Клиент доволен?
▪️ Инциденты прекратились?
▪️ Значит, проблема решена.
▪️ И артефакт (документ, статья, чек-лист) — сохранён для команды.
Кто участвует?
▪️ Problem Manager - не техник, а аналитик.
Он видит систему, а не только симптомы.
▪️ L2/L3, SRE, DevOps, разработка - те, кто может глубоко копать.
▪️ Incident Manager - передаёт контекст: что, где, сколько раз.
▪️ Knowledge Manager - фиксирует решение, чтобы оно не потерялось.
Зачем это измерять?
Потому что:
▪️ Сколько проблем выявлено и закрыто?
Если ноль — значит, вы не смотрите.
▪️ Среднее время на решение проблемы
Не торопитесь. Главное — качество анализа.
▪️ Снижение количества инцидентов после решения
Это и есть доказательство эффективности.
▪️ Доля инцидентов, связанных с известными проблемами
Если высокая - у вас есть «дыра», которую давно пора закрыть.
Типичные ошибки
▪️ Не начинают вовремя
Ждут, пока станет «очень плохо».
▪️ Смешивают с Incident Management.
Инженер пытается «починить и разобраться» одновременно.
Не получается.
▪️ Не фиксируют артефакты.
Решение «в голове» - это не решение.
Это риск.
▪️ Не передают в Change Management.
«Поправили вручную» - и снова ждут, пока упадёт.
Итог
Incident Management - это пожарная команда
Problem Management - это инженер, который проверяет проводку.
Хороший процесс - это когда пожаров становится всё меньше.
#ProblemManagement #ITIL #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥6
Недавно меня позвала одна молодая, но дерзкая онлайн-школа, которая растит инженеров технической поддержки.
Приглашение звучало так:
«Ринат, ты должен быть headliner. С нас sold out.»
Ну как тут откажешь?
Пришёл. Поговорили.
Они - с вопросами. Я - с ответами.
Что хотели знать больше всего?
Как не просто выживать в поддержке - а расти.
Куда смотреть. Что учить. Как не сгореть.
Как из L1-2 - вырасти в того, кого все зовут, когда «всё горит».
В посте ниже подборка материалов, которые работают:
▪️ по hard skills: Linux, сети, SQL, API, Docker, Kubernetes, Python;
▪️ по soft skills: как говорить с клиентом, не срываться, объяснять сложное - и оставаться в живых.
📌 Подборка живая - буду дополнять, обновлять, выкидывать устаревшее.
Если что-то пропустил - пиши в комменты, скажу спасибо.
Читай. Учись. Применяй.
#TechSupport #Книги
Приглашение звучало так:
«Ринат, ты должен быть headliner. С нас sold out.»
Ну как тут откажешь?
Пришёл. Поговорили.
Они - с вопросами. Я - с ответами.
Что хотели знать больше всего?
Как не просто выживать в поддержке - а расти.
Куда смотреть. Что учить. Как не сгореть.
Как из L1-2 - вырасти в того, кого все зовут, когда «всё горит».
В посте ниже подборка материалов, которые работают:
▪️ по hard skills: Linux, сети, SQL, API, Docker, Kubernetes, Python;
▪️ по soft skills: как говорить с клиентом, не срываться, объяснять сложное - и оставаться в живых.
📌 Подборка живая - буду дополнять, обновлять, выкидывать устаревшее.
Если что-то пропустил - пиши в комменты, скажу спасибо.
Читай. Учись. Применяй.
#TechSupport #Книги
🔥9👍1
Читай и изучай в свободное время.
Не для галочки - чтобы проникаться, вариться, расти.
Твой путь в топ.
Легенда:
😎 - легко, сходу
🤓 - норм, но мозг включить надо
🙈 - сложнА
💻 База
▪️ Архитектура компьютера - Эндрю Таненбаум 🙈
▪️ Как работают компьютеры - Джастис Мэтью 🙈
🐧 Linux
▪️ Внутреннее устройство Linux - Брайан Уорд 🤓
▪️ Командная строка Linux. Полное руководство - Уильям Шоттс 🙈
☸️ Kubernetes / Docker
▪️ Kubernetes в действии - Марко Лукша 🤓
▪️ Docker. Вводный курс - Шая Кейн 🤓
🌐 Сети
▪️ Сети для самых маленьких (СДСМ) 😎
▪️ Компьютерные сети - Таненбаум / Олиферы 🤓
🐍 Python
▪️ Автоматизация рутинных задач с помощью Python - Эл Свейгарт 🙈
▪️ Python в системном администрировании UNIX и Linux - Ноа Гифт, Джереми М. Джонс 🤓
📊 SQL
▪️ Изучаем SQL - Алан Бьюли 🤓
🎓 Курсы
▪️ Selectel School 😎
▪️ Кирилл Семаев: видеокурсы по Linux 😎
▪️ Иннокентий Солнцев: курсы по сетям 😎
❤️ Клиентский сервис
▪️ ВкусВилл: Как совершить революцию в ритейле, делая всё не так - много про сервис внутри 😎
▪️ Книга про бизнес и сервис - Марина Вострикова 😎
▪️ Обнимите своих клиентов - Джек Митчелл 😎
▪️ Первоклассный сервис как конкурентное преимущество - Джон Шоул 😎
▪️ Доставляя счастье - Шей Тони 😎
▪️ Пиши, сокращай - Максим Ильяхов 😎
⏰ Тайм-менеджмент
▪️ Time Management for SysAdmins - Томас Лимонцелли 😎
▪️ Джедайские техники - Максим Дорофеев 😎
#TechSupport #Книги #Курсы
Не для галочки - чтобы проникаться, вариться, расти.
Твой путь в топ.
Легенда:
😎 - легко, сходу
🤓 - норм, но мозг включить надо
🙈 - сложнА
💻 База
▪️ Архитектура компьютера - Эндрю Таненбаум 🙈
▪️ Как работают компьютеры - Джастис Мэтью 🙈
🐧 Linux
▪️ Внутреннее устройство Linux - Брайан Уорд 🤓
▪️ Командная строка Linux. Полное руководство - Уильям Шоттс 🙈
☸️ Kubernetes / Docker
▪️ Kubernetes в действии - Марко Лукша 🤓
▪️ Docker. Вводный курс - Шая Кейн 🤓
🌐 Сети
▪️ Сети для самых маленьких (СДСМ) 😎
▪️ Компьютерные сети - Таненбаум / Олиферы 🤓
🐍 Python
▪️ Автоматизация рутинных задач с помощью Python - Эл Свейгарт 🙈
▪️ Python в системном администрировании UNIX и Linux - Ноа Гифт, Джереми М. Джонс 🤓
📊 SQL
▪️ Изучаем SQL - Алан Бьюли 🤓
🎓 Курсы
▪️ Selectel School 😎
▪️ Кирилл Семаев: видеокурсы по Linux 😎
▪️ Иннокентий Солнцев: курсы по сетям 😎
❤️ Клиентский сервис
▪️ ВкусВилл: Как совершить революцию в ритейле, делая всё не так - много про сервис внутри 😎
▪️ Книга про бизнес и сервис - Марина Вострикова 😎
▪️ Обнимите своих клиентов - Джек Митчелл 😎
▪️ Первоклассный сервис как конкурентное преимущество - Джон Шоул 😎
▪️ Доставляя счастье - Шей Тони 😎
▪️ Пиши, сокращай - Максим Ильяхов 😎
⏰ Тайм-менеджмент
▪️ Time Management for SysAdmins - Томас Лимонцелли 😎
▪️ Джедайские техники - Максим Дорофеев 😎
#TechSupport #Книги #Курсы
🔥11👍5💯4👎1
Как устроена техническая поддержка в Яндекс.Клауде?
Докладов про поддержку мало.
Толковых - ещё меньше.
А между тем, в крупном облачном провайдере поддержка - не просто «дежурный у телефона».
Это система, в которой всё продумано: от найма до культуры, от автоматизации до KPI, от первого тикета до инцидента уровня P0.
В докладе - разбор изнутри.
Не про теорию.
Про то, как это работает на практике.
Что узнаете:
▪️ Как организована поддержка в крупном облачном провайдере?
- Три линии
- L1 решает большую часть запросов, L2 и L3 - погружаются в сложные кейсы, работают с продуктами, участвуют в инцидентах.
- Поддержка - не «конвейер», а сеть экспертизы.
▪️ Сколько инженеров на каждой линии?
- Не просто цифры.
- Как они распределены по продуктам
▪️ Как и откуда они набирают людей?
- Не только по стеку и резюме.
▪️ Как устроен онбординг и развитие?
- Первые 90 дней - не «знакомство с системой», а глубокое погружение.
▪️ Что автоматизировали?
- Чтобы инженер мог решать проблему, а не искать её.
▪️ Чем занимаются L2/L3?
▪️ Какие KPI у инженеров и руководителей?
▪️ Как работают с инцидентами?
▪️ Что должна иметь любая ответственная компания?
▪️ Нужен ли Tone of Voice?
- Спойлер: Да.
▪️ Support - центр расходов или доходов?
▪️ Какая культура в команде?
Рекомендую.
Польза будет.
Однозначно.
#TechSupport
Докладов про поддержку мало.
Толковых - ещё меньше.
А между тем, в крупном облачном провайдере поддержка - не просто «дежурный у телефона».
Это система, в которой всё продумано: от найма до культуры, от автоматизации до KPI, от первого тикета до инцидента уровня P0.
В докладе - разбор изнутри.
Не про теорию.
Про то, как это работает на практике.
Что узнаете:
▪️ Как организована поддержка в крупном облачном провайдере?
- Три линии
- L1 решает большую часть запросов, L2 и L3 - погружаются в сложные кейсы, работают с продуктами, участвуют в инцидентах.
- Поддержка - не «конвейер», а сеть экспертизы.
▪️ Сколько инженеров на каждой линии?
- Не просто цифры.
- Как они распределены по продуктам
▪️ Как и откуда они набирают людей?
- Не только по стеку и резюме.
▪️ Как устроен онбординг и развитие?
- Первые 90 дней - не «знакомство с системой», а глубокое погружение.
▪️ Что автоматизировали?
- Чтобы инженер мог решать проблему, а не искать её.
▪️ Чем занимаются L2/L3?
▪️ Какие KPI у инженеров и руководителей?
▪️ Как работают с инцидентами?
▪️ Что должна иметь любая ответственная компания?
▪️ Нужен ли Tone of Voice?
- Спойлер: Да.
▪️ Support - центр расходов или доходов?
▪️ Какая культура в команде?
Рекомендую.
Польза будет.
Однозначно.
#TechSupport
RUTUBE
Как мы делаем Yandex Cloud — Support
В новом выпуске «Как мы делаем Yandex Cloud» познакомились с руководителем третьей линии поддержки Александром Житным. Обсудили, как устроена поддержка Yandex Cloud, чем занимаются команда автоматизации и AI-роботы, какие у команды KPI и принципы работы.…
🔥8👍7✍3👎1
Change Management
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину поломки.
Change Management - предотвращает сбои и улучшает сервис.
Если инцидент - пожар, проблема - неисправная проводка,
то Change - это разрешение на ремонт, проверенный план и подписанный акт.
Без него «быстрый фикс» становится бомбой.
Примеры:
▪️ Обновление операционной системы на критически важном сервере.
▪️ Развертывание новой версии корпоративного приложения.
▪️ Изменение конфигурации сетевого оборудования, чтобы увеличить пропускную способность.
▪️ Удаление устаревшего, неиспользуемого компонента инфраструктуры.
Что такое Change Management?
Это процесс контроля изменений в инфраструктуре, продуктах и процессах.
Не запрет на перемены.
А структура для безопасных изменений.
Основные цели Change Management
Цель - не замедлить.
Цель - предотвратить ущерб от "хорошей пятничной идеи в 20:37".
Почему это важно? Потому что:
▪️70% инцидентов начинаются с изменения.
▪️90% из них - с изменения, которое "никто не заметил".
▪️100% из них - с изменения, которое не прошло проверку.
1️⃣ Контроль рисков
Каждое изменение оценивается: что может пойти не так?
Кто пострадает?
Как откатим?
2️⃣ Минимизация сбоев
Не "сделаем и посмотрим".
А: протестируем → согласуем → внедрим → проверим.
3️⃣ Прозрачность и аудит
Где, что, кем и когда было изменено?
Теперь вы можете ответить на этот вопрос.
5️⃣ Координация между командами
Разработка, SRE, поддержка, безопасность - все в одном поле.
Никаких сюрпризов в релизе.
5️⃣ Сохранение стабильности сервиса
Не ради "процедуры".
А ради того, чтобы клиенты продолжали пользоваться сервисом.
Когда запускается Change Management?
Всегда.
Если изменение касается:
▪️кода,
▪️конфигурации,
▪️сети,
▪️доступов,
Все идёт через Change Request (CRQ).
Даже если:
▪️"это мелочь",
▪️"раньше так делали без согласования",
▪️"сроки горят".
Горящие сроки - не повод для горящего сервиса.
Как работает процесс?
1️⃣ Инициация изменения
Кто-то хочет что-то изменить.
Пишет CRQ:
▪️Что?
▪️Зачем?
▪️Как?
▪️Риски?
▪️План отката?
2️⃣ Оценка и согласование
Change Advisory Board (CAB) - или упрощённый аналог - смотрит:
▪️Нет ли конфликтов с другими изменениями?
▪️Есть ли ресурсы?
▪️Достаточно ли тестов?
▪️Кто утвердит?
3️⃣ Реализация
Изменение внедряется в согласованное окно.
С контролем, мониторингом, поддержкой на связи.
5️⃣ Проверка и закрытие
Работает ли?
Клиенты не страдают?
Метрики в норме?
→ Закрываем CRQ.
→ Фиксируем в базе знаний.
Кто участвует?
▪️Change Manager - не бюрократ, а координатор.
Он держит процесс в чистоте и вовремя.
▪️Заявитель - разработчик, инженер, SRE, менеджер продукта - кто инициирует изменение.
▪️CAB (Change Advisory Board) - представители поддержки, безопасности, SRE, продуктовой команды.
▪️Incident Manager / ТехПод - на связи, если что-то пойдёт не так.
Типичные ошибки
▪️«Это быстро, давайте без CRQ»
→ Быстро - не значит безопасно.
→ Без CRQ - без отката.
→ А значит, и без контроля.
▪️Change Management = бюрократия
Нет.
Это инструмент доверия.
Ты уверен, что никто не полезет в прод в пятницу вечером без плана.
▪️Не фиксируют результат
Решение есть.
CRQ закрыт.
А в базе знаний - пусто.
→ Через месяц - тот же инцидент.
Потому что "все забыли".
Зачем это измерять?
Потому что:
▪️Количество изменений, прошедших через процесс
Если 30% - значит, у вас полумрак.
Если 100% - значит, порядок.
▪️Процент изменений, вызвавших инциденты
Должен стремиться к нулю.
Если не стремится - где-то прорыв.
▪️Среднее время согласования
Не должно быть "ожидание 5 дней".
Но и не "подписали за 2 минуты".
▪️Доля экстренных изменений
Если больше 10% - значит, процесс не работает.
Люди обходят его.
Итог
Change Management - это тормоз.
Но не для прогресса.
Для хаоса.
Он не запрещает ехать.
Он не даёт врезаться.
#ChangeManagement #ITIL #TechSupport
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину поломки.
Change Management - предотвращает сбои и улучшает сервис.
Если инцидент - пожар, проблема - неисправная проводка,
то Change - это разрешение на ремонт, проверенный план и подписанный акт.
Без него «быстрый фикс» становится бомбой.
Примеры:
▪️ Обновление операционной системы на критически важном сервере.
▪️ Развертывание новой версии корпоративного приложения.
▪️ Изменение конфигурации сетевого оборудования, чтобы увеличить пропускную способность.
▪️ Удаление устаревшего, неиспользуемого компонента инфраструктуры.
Что такое Change Management?
Это процесс контроля изменений в инфраструктуре, продуктах и процессах.
Не запрет на перемены.
А структура для безопасных изменений.
Основные цели Change Management
Цель - не замедлить.
Цель - предотвратить ущерб от "хорошей пятничной идеи в 20:37".
Почему это важно? Потому что:
▪️70% инцидентов начинаются с изменения.
▪️90% из них - с изменения, которое "никто не заметил".
▪️100% из них - с изменения, которое не прошло проверку.
Каждое изменение оценивается: что может пойти не так?
Кто пострадает?
Как откатим?
Не "сделаем и посмотрим".
А: протестируем → согласуем → внедрим → проверим.
Где, что, кем и когда было изменено?
Теперь вы можете ответить на этот вопрос.
Разработка, SRE, поддержка, безопасность - все в одном поле.
Никаких сюрпризов в релизе.
Не ради "процедуры".
А ради того, чтобы клиенты продолжали пользоваться сервисом.
Когда запускается Change Management?
Всегда.
Если изменение касается:
▪️кода,
▪️конфигурации,
▪️сети,
▪️доступов,
Все идёт через Change Request (CRQ).
Даже если:
▪️"это мелочь",
▪️"раньше так делали без согласования",
▪️"сроки горят".
Горящие сроки - не повод для горящего сервиса.
Как работает процесс?
Кто-то хочет что-то изменить.
Пишет CRQ:
▪️Что?
▪️Зачем?
▪️Как?
▪️Риски?
▪️План отката?
Change Advisory Board (CAB) - или упрощённый аналог - смотрит:
▪️Нет ли конфликтов с другими изменениями?
▪️Есть ли ресурсы?
▪️Достаточно ли тестов?
▪️Кто утвердит?
Изменение внедряется в согласованное окно.
С контролем, мониторингом, поддержкой на связи.
Работает ли?
Клиенты не страдают?
Метрики в норме?
→ Закрываем CRQ.
→ Фиксируем в базе знаний.
Кто участвует?
▪️Change Manager - не бюрократ, а координатор.
Он держит процесс в чистоте и вовремя.
▪️Заявитель - разработчик, инженер, SRE, менеджер продукта - кто инициирует изменение.
▪️CAB (Change Advisory Board) - представители поддержки, безопасности, SRE, продуктовой команды.
▪️Incident Manager / ТехПод - на связи, если что-то пойдёт не так.
Типичные ошибки
▪️«Это быстро, давайте без CRQ»
→ Быстро - не значит безопасно.
→ Без CRQ - без отката.
→ А значит, и без контроля.
▪️Change Management = бюрократия
Нет.
Это инструмент доверия.
Ты уверен, что никто не полезет в прод в пятницу вечером без плана.
▪️Не фиксируют результат
Решение есть.
CRQ закрыт.
А в базе знаний - пусто.
→ Через месяц - тот же инцидент.
Потому что "все забыли".
Зачем это измерять?
Потому что:
▪️Количество изменений, прошедших через процесс
Если 30% - значит, у вас полумрак.
Если 100% - значит, порядок.
▪️Процент изменений, вызвавших инциденты
Должен стремиться к нулю.
Если не стремится - где-то прорыв.
▪️Среднее время согласования
Не должно быть "ожидание 5 дней".
Но и не "подписали за 2 минуты".
▪️Доля экстренных изменений
Если больше 10% - значит, процесс не работает.
Люди обходят его.
Итог
Change Management - это тормоз.
Но не для прогресса.
Для хаоса.
Он не запрещает ехать.
Он не даёт врезаться.
#ChangeManagement #ITIL #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍3✍2🤝1
FS_Benchmark_2024.pdf
24.5 MB
7 KPIs of world-class ITSM. Что показал Freshservice Service Management Benchmark Report 2024?
KPI - это не просто цифры. Это ваш GPS в мире ITSM.
На основе данных 9 400+ организаций, 100 стран и 167 миллионов(❗️ ) тикетов отчёт FBR 2024 выделил 7 ключевых метрик, которые определяют эффективность сервис-деска. Не теория. Реальные цифры. Реальный рынок.
Это не просто отчёт. Это бенчмарк для тех, кто хочет быть выше рынка.
7 KPI, по которым измеряют зрелость поддержки:
1️⃣ CSAT - 97,4%
Почти полное удовлетворение клиентов. Теперь это не достижение - это ожидание.
2️⃣ ART - 24,15 часа
Среднее время решения запроса. Ваш результат ближе к этому числу?
3️⃣ AFRT - 10,82 часа
Первый ответ. Чем быстрее, тем лучше. Каждый час ожидания — снижение доверия.
4️⃣ FCR - 73,9%
Доля тикетов, закрытых с первого контакта. Ниже? Значит, процесс хромает.
5️⃣ Resolution SLA - 95,7%
Соблюдение сроков решения. Большинство тикетов закрывается вовремя. Но не у всех.
6️⃣ First Response SLA - 95,5%
Сроки первого ответа соблюдаются почти всегда. Исключения - риск для репутации.
7️⃣ AFAT - 17,47 часов
Время до назначения тикета специалисту. Каждый час в очереди - потеря лояльности.
Эти цифры - медиана по рынку.
Если вы ниже - догоняйте.
Если выше - вы впереди.
Если намного выше - вы задаёте тренд.
Где взять прорыв по метрикам?
Отчёт чётко показывает: технологии работают. Но только если они правильные.
1️⃣ Reply Suggester → -38,68% к первому ответу
Предлагает готовые, контекстно-ориентированные ответы прямо в интерфейсе специалиста.
Основано на базе знаний, истории обращения и типе запроса.
Специалист не ищет, не формулирует - он отправляет.
Результат: первый ответ за 6,56 часов вместо 10,82.
2️⃣ Ticket Summary Generator → -32,16% к времени решения
Автоматически создаёт краткое резюме длинного тикета.
Выделяет суть проблемы, действия специалистов, комментарии клиента.
Специалист не читает 50 сообщений - он видит суть за 10 секунд.
Итог: на треть быстрее закрываются сложные тикеты.
3️⃣ Help Article Generator → +15,48% к эффективности базы знаний
Автоматически создаёт статьи на основе реальных тикетов, переписок и внешних источников.
Решения из опыта специалистов сразу становятся доступны всей команде.
База знаний живёт и растёт без ручного труда.
Self-service становится мощнее. Повторяющиеся тикеты исчезают.
Итог
FBR 2024 - это не про «что делают другие».
Это про то, какие действия дают прирост.
Не гадайте.
Сравнивайте.
Улучшайте.
#Исследования #Тренды #TechSupport #Метрики
KPI - это не просто цифры. Это ваш GPS в мире ITSM.
На основе данных 9 400+ организаций, 100 стран и 167 миллионов(
Это не просто отчёт. Это бенчмарк для тех, кто хочет быть выше рынка.
7 KPI, по которым измеряют зрелость поддержки:
Почти полное удовлетворение клиентов. Теперь это не достижение - это ожидание.
Среднее время решения запроса. Ваш результат ближе к этому числу?
Первый ответ. Чем быстрее, тем лучше. Каждый час ожидания — снижение доверия.
Доля тикетов, закрытых с первого контакта. Ниже? Значит, процесс хромает.
Соблюдение сроков решения. Большинство тикетов закрывается вовремя. Но не у всех.
Сроки первого ответа соблюдаются почти всегда. Исключения - риск для репутации.
Время до назначения тикета специалисту. Каждый час в очереди - потеря лояльности.
Эти цифры - медиана по рынку.
Если вы ниже - догоняйте.
Если выше - вы впереди.
Если намного выше - вы задаёте тренд.
Где взять прорыв по метрикам?
Отчёт чётко показывает: технологии работают. Но только если они правильные.
Предлагает готовые, контекстно-ориентированные ответы прямо в интерфейсе специалиста.
Основано на базе знаний, истории обращения и типе запроса.
Специалист не ищет, не формулирует - он отправляет.
Результат: первый ответ за 6,56 часов вместо 10,82.
Автоматически создаёт краткое резюме длинного тикета.
Выделяет суть проблемы, действия специалистов, комментарии клиента.
Специалист не читает 50 сообщений - он видит суть за 10 секунд.
Итог: на треть быстрее закрываются сложные тикеты.
Автоматически создаёт статьи на основе реальных тикетов, переписок и внешних источников.
Решения из опыта специалистов сразу становятся доступны всей команде.
База знаний живёт и растёт без ручного труда.
Self-service становится мощнее. Повторяющиеся тикеты исчезают.
Итог
FBR 2024 - это не про «что делают другие».
Это про то, какие действия дают прирост.
Не гадайте.
Сравнивайте.
Улучшайте.
#Исследования #Тренды #TechSupport #Метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥5❤2🤝1
КтоЕстьКто в ТехПоде
За последнее годы, я провел больше 400 собеседований на tech и руководящие позиции, и этот опыт позволил мне сформулировать два ключевых наблюдения:
1️⃣ Успех приходит тогда, когда тебе не нужно «заставлять» себя работать, потому что процесс приносит радость. Когда твоя job становится хобби, ты не «ищешь время» на развитие, а просто не можешь без него жить. Следить за трендами, смотреть доклады с конференций, быть на острие - это не обязанность, а естественное состояние.
2️⃣ Существует разрыв в ожиданиях. Часто талантливые люди просто не понимают, каких конкретно знаний и навыков от них ждут на той или иной позиции. Они теряются в догадках, куда двигаться дальше.
Чтобы закрыть этот разрыв, я запускаю серию постов #КтоЕстьКто в #ТехПод с фокусом на роли в индустрии облачных провайдеров.
В первом выпуске разберем инженера технической поддержки 1-й линии (L1). Это тот самый старт, с которого начинаются многие великие карьеры в IT.
Вместе разберем:
▪️Что это за роль на самом деле
▪️Какие требования действительно важны
▪️Куда растут лучшие инженеры L1
А в конце серии постов вас ждет небольшой бонус -откровенный разговор о том, сколько можно зарабатывать на каждой из разобранных позиций.
#КтоЕстьКто #ТехПод #TechSupport
За последнее годы, я провел больше 400 собеседований на tech и руководящие позиции, и этот опыт позволил мне сформулировать два ключевых наблюдения:
Чтобы закрыть этот разрыв, я запускаю серию постов #КтоЕстьКто в #ТехПод с фокусом на роли в индустрии облачных провайдеров.
В первом выпуске разберем инженера технической поддержки 1-й линии (L1). Это тот самый старт, с которого начинаются многие великие карьеры в IT.
Вместе разберем:
▪️Что это за роль на самом деле
▪️Какие требования действительно важны
▪️Куда растут лучшие инженеры L1
А в конце серии постов вас ждет небольшой бонус -
#КтоЕстьКто #ТехПод #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥5
КтоЕстьКто: Инженер технической поддержки 1-й линии (L1 Support Engineer)
Обзор роли
Инженер L1 в облачном провайдере - это первая и ключевая точка контакта между клиентом и компанией. Основная задача - приём обращений, первичная диагностика и решение базовых инцидентов, связанных с облачной инфраструктурой и сервисами клиента. Роль требует понимания облачных технологий и направлена на максимально быстрое восстановление работоспособности услуг или грамотную эскалацию для минимизации времени простоя.
Цель позиции
Обеспечить оперативное и квалифицированное реагирование на входящие запросы клиентов, эффективно используя инструменты мониторинга и базу знаний. Минимизировать время на первичную обработку и эскалацию инцидентов, соблюдая SLA и обеспечивая высокий уровень клиентского сервиса.
Кому подходит роль
▪️ Выпускникам технических вузов, интересующимся облачными технологиями
▪️ Кандидатам, которые хотят построить карьеру в одной из самых востребованных областей IT
▪️ Тем, кто готов учиться, обладает развитыми коммуникативными навыками и хочет работать в динамичной среде
Роль и обязанности
▪️ Приём и обработка запросов клиентов
▪️ Приём инцидентов от клиентов через выделенные каналы связи: тикет-система, телефон, портал
▪️ Профессиональное и вежливое общение, направленное на уточнение и понимание сути проблемы
▪️ Проверка прав клиента на получение технической поддержки по договору
Первичная диагностика и решение
▪️ Оперативный сбор информации: идентификаторы облачных ресурсов (ID инстанса, ID проекта), ошибки с консоли управления, логи, скриншоты
▪️ Проведение базовой диагностики с использованием внутренних инструментов мониторинга и панелей управления: дашборды состояния сервисов, метрики виртуальных машин, статус сетевых интерфейсов
▪️ Решение распространённых проблем:
• Консультации по настройке и использованию панели управления (Cloud Console)
• Проблемы с доступом к виртуальным машинам (ВМ) через SSH/RDP
• Сброс паролей или ключей доступа к ВМ
• Консультации по работе с базовыми сервисами (объектное хранилище, CDN, базы данных)
• Проверка доступности сервисов в зоне клиента и идентификация массовых инцидентов
Эскалация инцидентов
▪️ Чёткое определение категории проблемы: сбой платформы, сетевые проблемы, проблемы с производительностью, консультационный запрос
▪️ Назначение тикетов соответствующим экспертным командам: L2/L3, сетевым инженерам, инженерам по хранению данных, специалистам по виртуализации - с полным комплектом собранной информации
▪️ Мониторинг статуса эскалированных тикетов и поддержание коммуникации с клиентом о прогрессе
Документирование и управление знаниями
▪️ Ведение детальной и точной записи по каждому инциденту в системе Service Desk
▪️ Создание и обновление статей в базе знаний на основе повторяющихся запросов: How-To, частые ошибки, рекомендации
▪️ Ведение внутренней документации по процедурам эскалации
Требования к навыкам
Обязательные Hard Skills
▪️ Базовое понимание облачных концепций: IaaS, PaaS, виртуальные машины, виртуальные сети, блочное и объектное хранилище
▪️ Базовые знания сетевых технологий: понимание TCP/IP, DNS, HTTP(S); умение использовать ping, traceroute, nslookup, curl для первичной диагностики
▪️ Основы безопасности: понимание разницы между логином/паролем и ключевой парой SSH, принципов работы файрволов
▪️ Работа с API: базовое понимание REST, методов запросов, кодов ответов
▪️ Опыт работы с CLI (командной строкой) на базовом уровне в Linux: работа с файловой системой, основные команды - ls, cd, cat, grep, ps, chmod, chown
▪️ Английский язык на уровне чтения технической документации (как минимум)
Продолжение в комментариях
#КтоЕстьКто #TechSupport
Обзор роли
Инженер L1 в облачном провайдере - это первая и ключевая точка контакта между клиентом и компанией. Основная задача - приём обращений, первичная диагностика и решение базовых инцидентов, связанных с облачной инфраструктурой и сервисами клиента. Роль требует понимания облачных технологий и направлена на максимально быстрое восстановление работоспособности услуг или грамотную эскалацию для минимизации времени простоя.
Цель позиции
Обеспечить оперативное и квалифицированное реагирование на входящие запросы клиентов, эффективно используя инструменты мониторинга и базу знаний. Минимизировать время на первичную обработку и эскалацию инцидентов, соблюдая SLA и обеспечивая высокий уровень клиентского сервиса.
Кому подходит роль
▪️ Выпускникам технических вузов, интересующимся облачными технологиями
▪️ Кандидатам, которые хотят построить карьеру в одной из самых востребованных областей IT
▪️ Тем, кто готов учиться, обладает развитыми коммуникативными навыками и хочет работать в динамичной среде
Роль и обязанности
▪️ Приём и обработка запросов клиентов
▪️ Приём инцидентов от клиентов через выделенные каналы связи: тикет-система, телефон, портал
▪️ Профессиональное и вежливое общение, направленное на уточнение и понимание сути проблемы
▪️ Проверка прав клиента на получение технической поддержки по договору
Первичная диагностика и решение
▪️ Оперативный сбор информации: идентификаторы облачных ресурсов (ID инстанса, ID проекта), ошибки с консоли управления, логи, скриншоты
▪️ Проведение базовой диагностики с использованием внутренних инструментов мониторинга и панелей управления: дашборды состояния сервисов, метрики виртуальных машин, статус сетевых интерфейсов
▪️ Решение распространённых проблем:
• Консультации по настройке и использованию панели управления (Cloud Console)
• Проблемы с доступом к виртуальным машинам (ВМ) через SSH/RDP
• Сброс паролей или ключей доступа к ВМ
• Консультации по работе с базовыми сервисами (объектное хранилище, CDN, базы данных)
• Проверка доступности сервисов в зоне клиента и идентификация массовых инцидентов
Эскалация инцидентов
▪️ Чёткое определение категории проблемы: сбой платформы, сетевые проблемы, проблемы с производительностью, консультационный запрос
▪️ Назначение тикетов соответствующим экспертным командам: L2/L3, сетевым инженерам, инженерам по хранению данных, специалистам по виртуализации - с полным комплектом собранной информации
▪️ Мониторинг статуса эскалированных тикетов и поддержание коммуникации с клиентом о прогрессе
Документирование и управление знаниями
▪️ Ведение детальной и точной записи по каждому инциденту в системе Service Desk
▪️ Создание и обновление статей в базе знаний на основе повторяющихся запросов: How-To, частые ошибки, рекомендации
▪️ Ведение внутренней документации по процедурам эскалации
Требования к навыкам
Обязательные Hard Skills
▪️ Базовое понимание облачных концепций: IaaS, PaaS, виртуальные машины, виртуальные сети, блочное и объектное хранилище
▪️ Базовые знания сетевых технологий: понимание TCP/IP, DNS, HTTP(S); умение использовать ping, traceroute, nslookup, curl для первичной диагностики
▪️ Основы безопасности: понимание разницы между логином/паролем и ключевой парой SSH, принципов работы файрволов
▪️ Работа с API: базовое понимание REST, методов запросов, кодов ответов
▪️ Опыт работы с CLI (командной строкой) на базовом уровне в Linux: работа с файловой системой, основные команды - ls, cd, cat, grep, ps, chmod, chown
▪️ Английский язык на уровне чтения технической документации (как минимум)
Продолжение в комментариях
#КтоЕстьКто #TechSupport
👍13🔥4❤2