Периодически мне задают вопрос: "Кто есть кто в мире ИТ?". Вопрос этот интересный и объёмный. Вот сейчас я взял более 20 разновидностей «айтишников» и понимаю, что даже все основные разновидности не перечислил. Чтобы не рассказывать всё по много раз, я напишу несколько статей и буду на них ссылаться. Рассказывать буду простым языком, идя от простого к сложному.
Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп и стал одним из идеологов концепции IT~BP — IT бизнес-партнёрства https://itbp.org.
В IT работают не только и не столько программисты. Ситуация, в целом, здесь такая же, как с врачами: есть множество различных специалистов, в которых разобраться сможет только профессионал. Однако разницу между кардиохирургом и проктологом можно ощутить на интуитивном уровне. Попытаюсь рассматривать разновидности специалистов от простого к сложному.
Какие вообще бывают виды IT-специалистов?
Важно помнить, что есть виды IT-специалистов, а есть должности, грейды, категории и прочее. Их не стоит путать. Должность человека может называться, как угодно. Генеральный директор с 10 годами руководства фирмой в 5 человек не сможет выполнять функции генерального директора корпорации с десятками тысяч сотрудников. Должности у них называются одинаково, но суть их работы не совпадает.
Видов IT-специалистов много, я смогу рассмотреть только часть от основных. Однако этого должно хватить для того, чтобы (в отсутствии технического директора) понять какие IT-специалисты нужны компании, либо чтобы понять, кем хочется стать в IT-мире. Я собираюсь рассмотреть следующие разновидности:
Эникейщик
Специалист технической поддержки второй линии (L2)
Специалист технической поддержки третьей линии (L3)
Системный администратор
Программист (это не ошибка и не повторение пункта №7)
Младший программист (junior developer)
Рядовой программист (middle developer)
Старший программист (senior developer)
Руководитель службы технической поддержки
Технический лидер (tech lead)
Лидер команды разработки (team lead)
Инженер по тестированию (QC - quality control)
Инженер по качеству (QA - quality assurance)
DevOps инженер
Бизнес-аналитик
Системный-аналитик
UI/UX специалист
Руководитель продукта (product owner)
Руководитель проекта (project manager)
Архитектор решений (solution architect)
Системный архитектор (system\enterprise architect)
Функциональный архитектор (functional architect)
Начать здесь стоит с волшебных слов: «Ты ж программист», на бытовом уровне почему-то считается, что «программисты» понимают всё, что связанно с цифровой техникой. После того, как прозвучало «Ты ж программист», может последовать всё, что угодно. Хорошо если просьба подключить цифровую приставку к телевизору либо помочь разобраться в личном кабинете какой-нибудь программы, но может быть что-то совсем невообразимое, вплоть до сдачи бухгалтерской отчётности. Нет, ну а что? Та же 1С запускается на компьютере, кнопки там есть, значит программист справится…
Тем не менее, программисты действительно обладают базовыми техническими знаниями, могут разобраться, как подключить приставку к телевизору, переустановить Windows либо даже установить Linux. Это всё несложные действия, которые могут выполнять практически все люди, которые интересуются компьютерной техникой. Им просто это интересно, поэтому они это либо делали, либо могут понять, как это сделать.
Эникейщик
Это некий IT-специалист самого начального уровня, который помогает пользователям решать их небольшие проблемы. Название шутливое, произошло от надписи: «Press any key» («Нажмите любую клавишу»), когда-то эта надпись могла пугать пользователей и они звали эникейщика, чтобы он всё починил.
На самом деле это и есть тот самый «Ты ж программист». Такой человек может помочь с принтером, зажевавшем бумагу, заказать заправку картриджа этого самого принтера, помочь установить какой-то драйвер либо какую-то программку, либо просто вернуть кабель от монитора в гнездо, чтобы он начал работать. Эникейщик решает простые проблемы рядовых пользователей, опираясь на какой-то «бытовой набор» знаний об IT. Для такой работы не нужна высокая квалификации, хватит просто насмотренности в digital-мире.
У эникейшиков есть особая разновидность — компьютерный специалист на дом по вызову. Пока что не у всех людей в нашей стране высокая компьютерная грамотность, поэтому услуга всё ещё пользуется популярностью.
Если честно, то многие высококлассные и состоявшиеся IT-специалисты в молодости подрабатывали эникейщиками либо оказывали компьютерные услуги на дому. Хорошему IT-специалисту нужна небольшая предпринимательская жилка и желание помогать людям. Кроме того, такая работа развивает коммуникационные навыки, то, что потом будут называть «soft skills».
Специалист технической поддержки второй линии (L2)
Обычно в службе поддержки пользователей 3-4 уровня. На первом находится специалист колл-центра, который принимает заявки и может какие-то очевидные проблемы отработать по скрипту. На самом деле IT-специалисты не очень расположены часто общаться с людьми и предпочитают обитать в тихих и затемнённых помещениях, поближе к чаю и печенькам. Кроме того, хорошими коммуникационными навыками обладают не все IT-специалисты. Первая линия технической поддержки служит буфером между IT-специалистами и пользователями, у которых бывают разные эмоциональные состояния и коммуникационные навыки.
На второй линии находятся те же эникейщики, которые могут решать проблемы удалённо. Их снабжают базой знаний, в которой они могут находить алгоритмы решения типовых проблем. При этом мы помним, что для этого уже нужны технические знания. Кроме того, в случае если проблема сложная либо не типовая, специалист второй линии должен мочь грамотно описать проблему и передать её специалисту третьей линии. При этом попытавшись решить проблему пользователя обходными путями.
Стоит понимать, что квалификация специалиста второй линии зависит от сложности поддерживаемой системы. Если система сложная, то на этой позиции может находится, например, квалифицированный системный администратор.
Часто на второй линии работают молодые специалисты, которые недавно начали свой путь в IT. Со временем у таких людей растёт уровень квалификации, так называемые «hard skills», и они становятся системными администраторами, некоторые переходят на третью линию, становятся программистами либо ещё кем-то. Либо по мере роста «soft skills», при наличии навыков организации, можно вырасти в руководителя службы технической поддержки.
Когда специалисту технической поддержки второй линии не хватает знаний и возможностей, чтобы решить проблему пользователя, то ему на помощь приходит третья линия.
Специалист технической поддержки третьей линии (L3)
На третьей линии работают люди, которые разбирают нетиповые обращения пользователей и наполняют базу знаний для второй линии поддержки. Иногда они могут ещё и исправлять ошибки в коде. Если код не доступен, то локализуется и описывается ошибка, после чего она отправляется на 4 уровень, где находятся уже разработчики производителя решения.
Бывают случаи, когда силами третьей линии (если специалистам на этом уровне нечем заняться) осуществляется развитие системы, то есть они пишут код и выполняют доработки. Доработки могут идти по заказу стекхолдеров либо они могут выполняться, чтобы снизить количество ошибок пользователей и обращений на вторую линию.
Почему вдруг получилось так, что L3 нечем заняться? Потому что их задача — это снижать количество инцидентов и наполнять базу знаний для L2. Чем лучше они делают свою работу, тем меньше инцидентов до них доходит.
При этом получается странная ситуация, специалисты L3 должны постоянно быть на своём рабочем месте, так как критичный инцидент может прийти в любой момент, а эти самые критические инциденты могут случаться очень редко. Это как работа пожарной части, чем лучше профилактика, тем меньше вызовов.
Иногда специалисты третьей линии выполняют функции QA и Devops (о них расскажем в других частях), то есть выкатывают (переносят) обновления на продуктив. В крупных компаниях обычно разворачивают несколько версий продукта:
- для разработчиков, чтобы они могли отлаживать свой код (dev-стенд);
- для тестирования, чтобы процесс отладки кода не мешал процессу тестирования кода (test-стенд);
- для проверки итоговой версии перед обновлением для пользователей зачастую проводят повторное тестирование на копии данных с "боя" (preprod-стенд);
- версия, с которой работают конечные пользователи, она же "продуктив", она же бой.
Перед выкладкой обновлений на продуктив, сотрудники L3 могут их проверить на предпродуктовых стендах. Так как работа L3 связана с ошибками пользователей и программистов, то они кровно заинтересованы, чтобы не выпускать проблемные доработки на продуктив.
Как-то систематизировать уровень компетенции таких людей не представляется возможным. Это может быть как человек с начальными навыками программирования и администрирования, так и tech lead (технический лидер).
Например, когда я работал на третьей линии поддержки в БКС, у меня был международный сертификат Senior Developer и Senior Administrator по той платформе, на которой работал. На каждый из них нужно было сдать по 3-5 экзаменов. Я уже почти прошёл сертификацию по информационной безопасности, но тут я покинул компанию. Ещё у меня было право исправлять код на продуктиве. Я им пользовался. Операция эта рискованная, но руки у меня на месте, значит я ошибок на продуктиве не совершал.
Системный администратор
Системные администраторы бывают разными и с разной квалификацией. Уровень у системных администраторов определяется тем же, что и у программистов. Мы коснёмся этого в следующей части. Но в целом системные администраторы это те люди, которые следят за состоянием аппаратного обеспечения (серверы и сетевое оборудование) и настройками сети. Кроме того, именно они отвечают за средства виртуализации (создание виртуальных серверов), настройки операционных систем на серверах, системы сбора логов и прочее программное обеспечение, которое относится к «инфраструктуре».
На иллюстрации мы можем видеть жука (bug). Мы все привыкли к тому, что баги это про программистов и тестировщиков. Но первый «баг» был чисто инфраструктурной проблемой (подробности в статье «Народное творчество: баги»).
Самой распространенной теорией является случай с Грейс Хоппер. Она работала в Гарвардском университете с ЭВМ Harvard Mark II. Устройство работало не так, как следовало. В итоге Грейс обнаружила между замкнувшими контактами сгоревшего мотылька (судя по внешним характеристикам). После этого госпожа Хоппер вклеила маленького диверсанта в свой технический отчёт и написала: «First actual case of bug being found» (Первый реальный случай обнаружения бага). Произошло всё это в 1946 году 9 сентября.
Сфера системного администрирования не менее объёмная и сложная, чем сфера программирования. Но системные администраторы скорее настраивают и обслуживают программное обеспечение и оборудование, а не разрабатывают новое программное обеспечение. Хотя они часто сами пишут код для автоматизации своей ручной работы и коммутаторов.
Настройка сетевого оборудования иногда тоже может являться программированием. Запрограммировать коммутатор от Cisco и коммутатор от MikroTik это две разные задачи и специализации.
Именно системные администраторы будут заводить новых пользователей, настраивать им права, делить сеть на сегменты, настраивать VPN и многое другое. Обеспечение информационной безопасности, подготовка к отражению хакерских и DDoS атак, непосредственно отражение атак на инфраструктуру — это тоже работа системных администраторов. Иногда им в этом помогают специалисты службы информационной безопасности и специалисты технической поддержки 3 уровня.
Если взять тех же «хакеров», то нужно понимать, что у них больше развиты не навыки программирования, а навыки системного администрирования. Например, чтобы произвести DDoS-атаку, нужен «бот-нет», то есть целая сеть различных компьютеров (заражённых вирусом), объединённых в единую сеть, которые по команде начинают согласованную атаку заданной цели.
Специальное программное обеспечение (тот самый «вирус») для организации «бот-нета» можно купить. Но это не даст гарантии, что «бот-нет» получится.
Подводя промежуточные итоги
В первой части мы с вами рассмотрели вопрос о том, какими вообще бывают IT-шники, и составили список разновидностей специалистов, которых хотим рассмотреть. Список далеко не полный, специализациё на самом деле больше.
Вторая часть будет про программистов. Сначала мы поймём, что такое программист вообще, затем почему есть младшие (junior), средние (middle) и старшие (senior) программисты. Похожее разделение по аналогичным причинам бывает у системных администраторов, инженеров по качеству, менеджеров проектов и других специализаций.
Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.
Полезные материалы по теме:
- IT для неайтишников: Зачем оно нужно?
- IT для неайтишников: Какими бывают IT-шники? Часть 1
- IT для неайтишников: Какими бывают IT-шники? Часть 2
- IT для неайтишников: Какими бывают IT-шники? Часть 3
- IT для неайтишников: Какими бывают IT-шники? Часть 4
- IT для неайтишников: Какими бывают IT-шники? Часть 5
- IT для неайтишников: Куда исчезают программисты после 40 лет?
- IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
- IT для неайтишников: Технический долг или почему теперь всё так долго?
- Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
- Процессы в ИТ: Долго, дорого и не то
- Саморегуляция в ИТ: минимально допустимая эффективность работы
- Telegram-канал Записки ITBP (короткие сообщения)
- Канал на Дзен Записки ITBP (статьи среднего размера)
А data team, наверное, в группе бизнес аналитиков будет? Я имею в виду, data engineer, data analyst, data science и business intelligence developer/analyst
не, бизнес-аналитики и нормальные аналитики это разные вещи. Бизнес-аналитики блок-схемы рисуют. А аналитики - сами знаете
Просто автор описал в меру своего понимания
В IT вряд ли есть понятие «нормальный» аналитик. Бизнес-аналитики не только схемы рисуют, они еще требования собирают и занимаются их первоначальной упаковкой. Системные аналитику уже рассматривают систему на уровне потоков данных. Если же мы возьмем «дата сайентисов», то это совершенно иная область. Да, там есть свои аналитики, которые делают совершенно иной анализ. И на этом аналитики в ИТ не закончится.
Только давайте не забывать, что это все же «IT для неайтишников», сильно глубоко заплывать не стоит. :о)
Под нормальным я называю дата аналитиков и примкнувшим к ним дата-саентистов (их сферы знаний пересекаются процентов на 50 или более)
Помимо перечисленных, есть еще и BI-аналитики (дашборды рисуют)
Вы вон, аж 3 линии саппортов расписали. А зачем? потому что Вы в этом варитесь и для Вас это важно. Нормальному человеку глубоко пофиг какая линия его саппортит. Первая, вторая, третья, десятая. Ему важно решение его проблем и этим занимается саппорт
На самом деле нет. Проблема, как понять IT являясь неайтишником, обычно у простого человека не появляется. Чаще всего это представитель бизнеса, которому нужно что-то получить от IT, но как это сделать они не понимают. Именно поэтому сначала расписывается техническая поддержка, так как с нее все и начинается. Что такое L1\L2\L3 бизнес очень хорошо понимает.
Что до дата-аналитиков, то как раз из-за BI стоит их упомянуть, это направление становится актуальным для бизнесе.
У Вас проф. деформация. Бизнесу пофиг на ваши уровни поддержки. Хоть их там 10, бизнесу нужно эффективное решение задач, а не цветовая дифференциация штанов у этих мальчиков в свитерах
Вот я только на прошлой неделе объяснял людям, что такое ITIL/ITSM и что все уже придумано до них.
И бизнесу не пофиг, ему нужна система мониторинга того, какие реально проблемы возникают у пользователей, какой реальный результат имеют вносимые изменения, где реально есть узкие места. Это все техническая поддержка.
Система мониторинга наверно нужна, но зачем бизнесу эти 3-10 уровней поддержки. Это внутренне дело саппорт-подразделения. Вон, в сериале "айти крауд" сколько было уровней поддержки? да хер знает, было 2 парня, они все решали. Думаете их директору было важно, 3 или 10 уровней поддержки у него?
И это типичная картина во многих организаций. Да, внутри подразделения могут для удобства (и экономии ФОТ) нанимать для эникея студентов, а для админства - админа. Но часто бывает и так, людей мало, все делают всё. И принтеры и серверы
ITIL прям указывает, что нужно именно 3 уровня поддержки? если их будет 2, 1, 4, 10 - все, нихрена не заработает?
Я не смотрю сериалы. В реальной жизни вам не хватит «2 парней», как минимум, часто поддержка осуществляется 24/7. То есть круглосуточно, без праздников и выходных.
Когда у вас много пользователей, то вам нужна целая воронка для их обработки. На первой линии высаживается колл-центр, который не IT-специалисты, но могут что-то решить по скриптам. На второй линии высаживаются не очень дорогие IT-специалисты, которые решают простые проблемы. Они тоже работают круглосуточно.
На третью линию высаживаются дорогие IT-специалисты. Часто они не работают круглосуточно, но готовы в любой момент подключиться к решению проблемы по звонку.
Говорить, что бизнесу все это не важно, не получится. Бизнес очень хорошо понимает, что такое SLA. При его обсуждении, в том числе, разбирается кто, на каких линиях и в каком количестве находится.
Реальная жизнь это и 2 парня, которые не работают круглосуточно. Круглосуточно работает поддержка у хостинга. Обычная компания ночью закрывается
А зачем Вы мне рассказываете про эти линии. Я Вас не про это спрашиваю.
Я ж говорю, у Вас проф. деформация. Вы почему-то думаете, что людям интересно как устроены линии поддержки. И как это пипец важно знать стороннему человеку
Окститесь, всем насрать. Людям важно, чтобы принтер работал, а бумага в нем своевременно появлялась
Наверное, потому, что я общаюсь с руководителями реальных компаний из МСБ, и знаю какие проблемы перед ними встают? Либо потому, что мы работаем с корпорациями, и знаем, как у них все внутри устроено?
Корпорации разные бывают и устроено там может быть по разному. Уж поверьте.
Первая линия поддержки может быть вообще не про IT, а про бизнес. И решают они вопросы клиентов, которые (вопросы) к IT вообще никаким боком - "я тут случайно деньги не туда отправил, как отозвать платеж" и т.п. И со "второй линией" они вообще не контактируют - если не могут решить проблему сами, обращаются к бизнесу, а те уже смотрят в чем проблема.
"Вторая линия" - т.н. сопровождение и поддержка. Они не решают проблемы клиентов. Они смотрят чтобы все работало как надо. Мониторят ошибки в джоблогах, ставят (и только они, никто больше) новые патчи на прод. В случае проблем могут откатить патч. Фиксируют дефекты промсреды и отправляют их на третью линию.
Третья линия - это уже аналитики и разработка. К ним идут все. Бизнес, когда увидели что что-то работает не так. Или когда требуется новая бизнес-логика или изменения в старой. Сопровождение когда обнаружили дефект (что-то падает - тогда собирают логи дампы, что-то тормозит - снимают PEX статистику)...
Так что схемы могут варьироваться в значительной степени.
Про сленг - тут вообще в каждой команде он может быть свой. "Бой", "поставка", "опция", "дисплейник", "аска"...
Про "архитектора решений" не слышал ни разу. Есть архитектор направления...
Чаще всего L1 - это не IT-шники. А вот третьей линией аналитики и разработка вряд ли смогут быть, нет, назвать их так можно, но быть они ей не смогут. Хватит первой же аварии на бою, когда откажет критический сервис, чтобы это понять. Люди не уложатся в SLA, в котором прописано время реакции и время решения.
Аналитики и разработчики могут располагаться на 4-й линией, там же где и вендоры решений. Чаще всего они занимаются либо исправлением обнаруженных на продуктиве ошибок, либо помогают решать проблемы (ведь кроме управления инцидентами есть еще и управление проблемами).
Что для архитектора решений, то это просто solution architect. Приложения бывают большими, внутри них бывает сложная архитектура. Если таких приложений в ИТ-ландшафте много, то нужен уже системный архитектор.
И если честно, то разновидностей этих «архитекторов» весьма много, я смог взять только основных.
Конечно, в компаниях могут быть свои названия, которые отличаются от общепринятых, но сути вещей это не отменит. Не так важно, как называется должность, как важно то, что реально делает человек.
Не, ну вам, конечно, виднее...
Хватит первой же аварии на бою, когда откажет критический сервис, чтобы это понять. Люди не уложатся в SLA, в котором прописано время реакции и время решения.Но читая такое, становится примерно понятно откуда берутся "вайтишники", от которых все отбиваются руками-ногами.
Я же написал - есть "сопровождение" (безо всяких там "линий") которое отвечает за работоспособность системы. У них свои регламенты действий в чрезвычайных ситуациях (кстати, время недоступности mission-critical систем в банках регламентируется регулятором и по ряду основных систем может исчисляться минутами, дальше уже штрафы со многими нулями - тут речь не об исправлении дефекта, а об его обходе, переходе на резервные ветки и т.п.).
А чтобы минимизировать вероятность дефекта существует сложная и длительная схема тестирования - компоненты, бизнес, нагрузка, интеграция, техтест, установка на прелайв... Ну и для каждой поставки всегда прописывается план установки и план отката для сопровождения.
А правка дефекта уже происходит в более спокойной обстановке.
Ну, теперь представьте, что у вас просто один из ЦОДов отвалился из-за чего из сегментов сетей вывалились какие-то фрагменты. Либо у вас в системе с десяток серверов, но внезапно DNS перестал резолвить. Или началась DDOS атака либо просто случился наплыв пользователей выше расчетного пика и система начала захлебываться.
В итоге вы имеет ряд аварийных ошибок, понять причину происхождения которых, не зная как устроена система внутри, просто невозможно. Равно как не получится перенастроить сервера и скоординировать свою работу с работой соседних команд для организации обходного пути. Вам не поможет в таких ситуациях внимательное тестирование, как и откатываться на предыдущие версии тоже не выйдет.
Другой случай, ваша система имеет интеграции с 20 другими системами, которые интегрированы с еще какими-то другими системами, причем цепочки интеграции очень длинные. И тут во всем этом многообразии не подписался с помощью ЭЦП важный документ, не прогрузились куда-то важные данные либо еще что-то. В результате чего в вашей области возник инцидент.
Не понимая, как вообще всё вокруг устроенно, у вас не получится его расследовать и понять причины его возникновения. А сроки могут быть очень жесткими.
Компетенций L2 на такое не хватает, скорости реакции разработчиков - тоже. Может быть, все происходит на выходных, то есть разработка будет доступна только через пару дней. Регламенты тоже не помогают, так как в них вы аварийную ситуацию во всем её многообразии расписать не сможете.
Вот это и является обычной работой для L3. Это аварийная команда, поэтому я и говорю про логику вещей.
Вы, видимо, слабо себе представляете как все это устроено.
Критические банковские сервера полностью изолированы от внешенего мира (есдинственная связь - очереди и ESB шина). Так что никакого DDOS там в принципе невозможно. Как и "что-то отвалилось".
Всегда есть горячий резерв, на который можно перевести все в течении минут.
"Наплыв пользователей" - на этот случай и проводится нагрузочное тестирование - есть регламенты сколько ресурсов сервера может быть занято в каждый момент времени (и там есть очень солидный запас - условно говоря, в штатном режиме нагрузка на сервер не может превышать 50-60%, точных цифр не скажу, конечно). И за этим постоянно следит сопровождение - если какой-то модуль начинает потреблять слишком много ресурсов, сразу предпринимаются необходимые действия и заводится дефект производительности.
И сопровождение отлично знает как устроена система изнутри.
И диагностика ошибок и сбоев - это неотъемлемая часть разработки. Без нее (каждая ошибка оставляет информацию для расследования) ни одна поставка в бой не уйдет.
И еще раз. Нет ни L2, ни L3. Есть служба сопровождения в составе которой в том числе, есть дежурная смена. Но все это одно подразделение. Которое обеспечивает бесперебойную работу. А "третья линия" - это уже те, кто выявляют и правит причины. Аналитика и разработка. Они же занимаются развитием системы, оптимизацией и т.п.
На бою никто никогда код править не будет - это чревато. Только откат, перевод на резерв или еще что-то. Потому что причины сбоя могут быть нетривиальны - кажется одно, а по факту причина совсем в другом месте. Например, кажущийся дефект логики на деле оказывается нарушением регламента заливки данных со стороны бизнеса.
Задача сопровождения здесь увидеть с какого момента началась проблема, откатить до предыдущего состояния и отдать на разбор в аналитику/разработку. А там уже по логам (все ходы записываются) анализируется где и почему выполнение не по той ветке пошло.
Если что-то начало регулярно падать - откат и предоставление логов/дампов - там все записано. В каком модуле, в какой строке, по какой причине упало.
Вы же пользуетесь банком? Ну так попробуйте вспомнить - как часто сталкиваете с ситуацией, когда массово платежи не проходят, картой не можете расплатиться и т.п. У крупных банков такое даже не раз в год и шум по этому поводу на всю страну сразу.
Кроме банков есть и другие крупные компании. При этом мы недавно наблюдали, как ряд крупных компаний, в том числе и банки, позакрывали свои сети для всех входящих из-за рубежа. Потому, что прошел ряд сильных DDoS атак с территории Украины и ФРГ. Как результат, множеству штатных и нештатных сотрудников, которые работали через VPN из-за рубежа, сказали, что всегда рады видеть их в офисе.
Но не суть. Вчера на несколько часов прилегли личные кабинеты для юридических компаний от Альфа-банка. Их потом штормило несколько дней. В другом немаленьком банке обнаружили сбои в отправке отчетов по ЮЛ на упрощенке в ФНС, можно ожидать пени.
Для части крупных ритейлеров в последние несколько лет не помогают нагрузочные тестирования, так как из-за ковида, войны и еще чего-нибудь пользователей может приходить выше расчетных показателей высокого сезона.
Нет, конечно, запас по ресурсам у серверов есть. Но когда у вас приложение начинает жрать оперативную память либо CPU или еще хуже, упирается в жесткий диск, потребление ресурсов может выстрелить вверх по экспоненте. Запас сам по себе гарантий не дает никаких.
Касательно качества логирования, могу сразу сказать, что оно очень часто недостаточное. Я хорошо видел, как это на самом работает в крупных компаниях, не в теории, а на практике. И как смежным системам приходилось постоянно дописывать свои логи.
Касательно «дежурной смены» в крупной компании. Там есть и L2, и L3, потому что это есть в SLA. Сколько людей одновременно находится на смене, я сказать не смогу. Если взять все системы, то это несколько сотен человек, просто чтобы представить себе масштабы мероприятия.
Аналитики и разработчики в SLA не участвуют, в лучшем случае их рассматривают, как L4, но могут вообще ни к какой линии не относить и заворачивать все в процесс управления проблемами.
Про исправления кода на бою. Лично наблюдал, как такое происходит. Лично получал срочные запросы от бизнеса на такое. Нет, в теории, конечно, такое делать нельзя. А вот на практике совсем иная картина. Прежде всего, в крупных организациях.
Ситуации, когда откатываться в предыдущее состояние бесполезно, я уже описывал. Кроме того, если вы при накате производили конвертацию данных и у вас кластера из баз данных стоят, то это становится очень сомнительной идеей. Если стоят не просто кластера, а кластера с «мастер-мастер» репликацией, то это уже совсем плохая идея.
Вам когда нибудь приходилось разбирать дампы памяти с ошибкой? Вот мне приходилось и не раз. Вы не увидите там ничего про модуль, строку и причину. И это при условии, что запись в лог попасть не успела. Кроме того, помним, что логи хранятся очень ограниченное время.
И наших компаний есть счета в Альфа-банке. Это неплохой банк, но падать они могут несколько раз в год. Вчера вот упали. Как раз нельзя было завести счета и подписать платёжки. Благо не наш клиент, могу об этом рассказывать.
Из реальной жизни. Компания, 350 человек численность, айти отдел (весь) - 3 человека. Плюс приходящий 1с-ник
Никаких мать его линий поддержки. Вот от слова совсем
Фигово Вы знаете, раз 3 линии поддержки расписали, а всех возможных аналитиков нет. Вам не дали доступа к штатке? обидно да, но вот
Сходите на вводные курсы от курсов по айти. Вам там больше расскажут, какие бывают айтишники
Если Вы глубок копаете в дифференциацию айти-специалистов, то копайте не только в сфере поддержки (которая Вам видима близка и родна, а также дорога), но и другие сферы. Перечисляйте всех аналитиков, всех тестеров (автоматизированное отличается от ручного, например)
Вы мне сейчас привели всего одну компанию из малого бизнеса. Вряд ли на ней весь бизнес заканчивается.
Причем, можно с ходу сказать, что имеет смысл перейти на облачную 1С и избавиться от приходящего 1С-ника.
В целом, такие компании могут спокойно жить на SaaS решениях, пользуясь чужой технической поддержкой.
А теперь вопрос на засыпку. В статье перечислены 22 специализации. При этом указанно, что это даже не все основные. На ваш взгляд, все 22 специализации относятся к технической поддержке?
350 человек это уже не малый бизнес. Сорян. вполне себе средний
"Критерии малого предприятия — годовой доход от 120 до 800 млн рублей и среднесписочная численность сотрудников от 15 до 100 человек." Получается, я еще лучше Вас в бизнесах разбираюсь что ли?
Облачная 1с или не облачная суть не меняет
В статье перечислены специальности, но почему именно саппорт разложена по уровням. Я и спрашиваю, нахрена? Как делить по уровням это дело руководителя саппорт подразделения. Будет ему удобно и возможно, будет 2 уровня, а надо и 10 наберет. С аналитиками кстати таже фигня. Возможно будет вообще один вид аналитиков, которые будут делать вообще все, от дашбордов, до срезов для маркетинга. А может быть разделение на кучу вариантов. В том числе веб-аналитик, фин-аналитик, аналитик по логистике (складам, закупкам) и много чего еще. Даже HR-аналитики бывают. прикиньте
Кстати, а где в Вашем перечне дизайнеры, верстальщики и прочие ребята с креативным мышлением?
Что до дизайнеров и верстальщиков. В перечне есть UI/UX-специалист. А верстальщиков я рассматривать просто не буду. На сайтиках жизнь не заканчивается и не начинается. Это слишком узкая ниша в IT. SEO тоже рассматривать не буду.
I/UX-специалист это не дизайнер и не верстальщик. Это разные специальности
Например, пятого уровня просто не предусмотрено.А разве верстальщик верстает только сайтики. Вот у мейлру, например, был (и наверно еще есть) отдел продуктового дизайна. Видимо сайтики делают, да. на 100500 посетитилей. Но это ж не важно, Главное чтобы было 3 уровня поддержки :)
кем не предусмотрено? методологией? а что мешает использовать свою методологию? Или Вы считаете, что Вы можете запретить людям вводить столько уровней, сколько им требуется?
Пятого уровня поддержки не предусмотрено логикой вещей. Если 4-й уровень - это исправление дефекта кодирования со стороны вендора решения, то что у вас на пятом-то уровне будет?
Вы мыслите в шаблоне какой-то методологии. Методология это не закон, чтобы его соблюдали от сих до сих. Методология написана конкретными людьми для решения их конкретных проблем. У другой организации может быть иные проблемы, люди, вызовы
Че будет на пятой ответит человек, который введет 5-й уровень. Откуда я знаю, я не начальник саппорт-службы.
Есть логика обстоятельств, она ограничивает набор проблем, потребностей и вызовов. И тут не вопрос методологии.
Вы мыслите в русле свой логике. в каком нить фейсбуке или гугле или эпле может быть своя методология и свои уровни. Потому что у них свои проблемы и свои методы их решения, которые им кажутся оптимальными "здесь и сейчас", Вплоть до создания отдельного департамента для хорошего человека
Если брать «фейсбук», «гугл» либо «эпл», то вряд ли. Особенно если понимать, что ISO 20000 во многом повторяет ITIL/ITSM. И что участие в создании таких промышленных стандартов эти самые «фейсбук», «гугл» либо «эпл» принимают непосредственное участие.
Конечно UI/UX это не дизайнер, это больше, чем дизайнер.
Что до верстальщика. Обратите внимание, как собирается фронт крупных приложений, это делают из компоентов. Работа верстальщика там не очень нужна.
Верстальщик вам нужен для сайтиков и email-рассылок.
У Вас просто неглубокое понимание за пределами "саппорта"
Я вас же уже спросил. Действительно все 22 перечисленных в начала статьи специализации на ваш взгляд относятся к саппорту? Вы, почему-то, решили не отвечать.
Вы путаете критерии для малого предприятия и малого бизнеса. Видите ли, есть большая разница в обротке на 800КК в розничной торговле и при оказании услуг. Конечно, с точки зрения упрощенки это все не так важно, но вот масштабы и сложность бизнеса просто несопоставимы.
Деления на уровни поддержки происходит не просто так, оно идет из SLA. Произвольного количества вы получить не сможете. Например, пятого уровня просто не предусмотрено. Да, иногда обходятся без первого либо четвертого. Если у вас только задачи на уровне эникейщика, то вам и второго уровня хватит.
Между сотрудниками L1, L2, L3 есть кардинальная разница, поэтому приходится объяснять, что такое L2, что такое L3.
Ну и с аналитиками. Допустим, системный аналитик сможет в бизнес-анализ, а вот бизнес-аналитик вряд ли сможет в системный-анализ. Дата-аналитик тоже в системный-анализ, скорее всего, не сможет. Получить «просто аналитика» не получится. Есть огромная разница между «пользовательским сценарием», API и элементами математической статистики.