Всем привет! Не так давно я подробно рассказала в цикле статей о своей работе в команде поддержки GlowByte. Сегодня хочу разложить по полочкам для интересующихся этим видам деятельности, в чем же кроются различия между разными линиями поддержки.

В заключительной части цикла статей расскажу про неочевидные навыки, которые я получила за 2.5 года работы в команде поддержки GlowByte. 

За время работы в поддержке GlowByte я познала навыки технического менеджмента. Это касается как Agile-проектов, так и support. Были периоды, когда в моей работе преобладало больше менеджерских задач, чем технических: нужно было проводить онбординг проекта, решать критические ситуации заказчика, выстраивать процессы эффективной коммуникации, ходить на 8 встреч в день и т. д. И я была рада получить такой опыт. Поэтому хочу рассказать историю про повышение soft-скилов.

Продолжаю свою историю о службе поддержки в GlowByte. (“Начало”, “Врываемся в DevOps”, “Ищем баги”, “Упрощаем работу в поддержке и познаем код”). Не раз я упоминала базу знаний. Пришло время рассказать, как она зародилась и чем стала сейчас. База знаний – это отдельный большой вопрос. С первых дней в GlowByte я оказалась в огромном потоке информации и боялась все забыть. А еще мне казалось странным, что коллеги передают знания из уст в уста и каждый новичок тратит большое количество времени на то, чтобы что-то узнать. Так что люди, у которых есть проблемы с коммуникацией или обучением (когда “в рот не вкладывают”), рисковали навсегда остаться на галерах. Передача знаний в моих глазах выглядела первобытной, и я подумала, что раз у других нет базы знаний, она будет у меня.

Когда-то мне сказали, что математики – ленивые люди, поэтому они придумывают себе инструменты для упрощения жизни. С сотрудниками службы поддержки все так же: мы максимально пытаемся упростить себе жизнь и автоматизировать все, что только можно автоматизировать. В предыдущей части я рассказывала про траблшутинг. В этой я поведаю о том, какие инструменты мы в GlowByte разрабатывали для автоматизации и упрощения своего труда.

В предыдущих частях (“Начало”, “Врываемся в DevOps”) я рассказывала о том, как опыт работы в команде сопровождения GlowByte быстро принес мне базовые знания Unix, работы с БД и SQL и навыки DevOps. В этой небольшой части я расскажу про траблшутинг, как я научилась анализировать массивные логи и следить за множеством метрик “здоровья” системы. Эта часть наиболее верно описывает то, что ожидают компании от технического инженера службы поддержки.

Продолжая серию статей про знания, полученные на работе, хочу рассказать про свои навыки DevOps, которые были на нуле, когда я пришла в компанию GlowByte. 

Это история о том, на что нужно обращать внимание, изучая инструменты DevOps с нуля, и как достичь успеха в этом.

В статье расскажу свою историю накопления знаний, какие задачи помогли лучше понять DevOps и как это все помогает специалисту поддержки.

Задумывались ли вы, какие скиллы в вас развила и развивает работа? Достаточный ли рост получаете в своей профессиональной деятельности? А нет ли такого, что вы занимаетесь изучением специфических космолетов, знания о которых применить больше негде, кроме как на текущем месте работы? На определенном этапе своей карьеры я задалась именно такими вопросами и в данной статье, точнее цикле статей, расскажу, как я научилась измерять свое развитие, управлять им и что дала мне работа в сопровождении B2B-бизнеса. 

Всем привет! Мы команда сопровождения GlowByte, занимаемся решением багов в различных системах крупного бизнеса. В статье на примере use-кейса расскажем, как разбирать закрытую систему по кусочкам в поисках решений сложных багов.

Однажды к нам пришёл проект, о котором не было известно ничего: вендор покинул российский рынок и оставил систему с закрытым исходным кодом без документации и экспертной команды. Рассказываем, как именно мы справились с работой над "чёрным ящиком", а также объясняем на примерах технические детали получения исходников из закрытого JAVA-кода.

Привет! Мы команда сопровождения GlowByte, и мы решаем сложные проблемы. Если проект не хочет брать на поддержку ни одна команда, если с проекта ушли все ключевые сотрудники, если проект бросили разработчики, если на проекте экзотические технологии или же проект захотел отказаться от технической поддержки и порушить все свои бизнес-процессы, то есть отличный повод прийти за помощью к нам. Это история о том, как иностранный вендор бросил крупный проект, о том, как мы пытались протянуть руку помощи, и о том, что мы точно делали НЕправильно.

Мы MM.SUP – команда сопровождения аналитического CRM компании GlowByte – хотим рассказать о том, как не усложнять все и прийти к простым и правильным решениям в сфере построения процессов сопровождения. Рассказ основан на собственном опыте нормализации процессов управления дефектами промышленной среды ведущего банка топ-5 России.