До «Белой Радуги» моё знакомство с карательной советско-российской стоматологией выглядело так: кругом — мышьяк, и в борьбе с пульпитом убивались все зубы, до которых можно было дотянуться. После этой «бережной» процедуры оставшиеся без нервов зубы методично разрушались и крошились, пока вместо жевательных зубов не оставались только острые обломки, о которые я постоянно резал язык. Правда, надо отметить: мой «фасад» до упора выглядел довольно неплохо, и после лечения улыбка внешне почти не изменилась. Но если я улыбался слишком уж широко, то в одном месте было видно золотую коронку, а в другом — большой провал. Жевательных зубов у меня почти не осталось. К тому же, честно говоря, с гигиеной всё было отвратительно, и изо рта у меня сильно пахло. Усугублял положение тот факт, что в последние 18 лет я много курил, и это тоже не добавляло дыханию свежести.

Всем привет! Я Артем Ибрагимов, руководитель направления в управлении разработки цифровых продуктов в Первой грузовой компании. Одна из составляющих работы любого продукта – это техподдержка. В ПГК есть несколько флагманских цифровых сервисов, где наши IT-специалисты на постоянной основе решают различные вопросы и проблемы пользователей. Ранее я подробно рассказал о работе техподдержки одного из наших продуктов – личного кабинета клиента (ЛКК) и оперативном решении возникающих задач. Сегодня поговорим о техподдержке не только ЛКК, но и других наших флагманских продуктов, а также об обратной связи по клиентской помощи.

Не так давно я написал заметку, где дал исторический очерк жизненного цикла Windows 10, рассказал о том, когда выходили разные версии (а их было как минимум 14) и до какой даты осуществляется обновление. Там же я давал рекомендации тем, кто не собирается переходить на Windows 11, как им получать обновления на свою Windows 10 еще более семи лет, до 13.01.2032.

Сегодня у меня задача понятным языком рассказать вам о Windows 11. Всегда непросто описывать современные системы и их текущие версии, - во-первых они слишком быстро меняются, обновляются, устаревают, а, во-вторых, просто накоплено не так много исторических знаний и опыта, что делает суждения более поверхностными и спорными. Для начала я расскажу о глобальных версиях Windows 11, - их всего 4 (в трех ветвях обслуживания). Потом остановлюсь на том, что такое «Моменты» в терминологии Microsoft, когда эти моменты наступали для Windows 11 и что они приносили. Далее я еще усложню рассказ тем, что раскрою секрет Полишинеля, - Microsoft вводит новый функционал не только в новых версиях ОС, не только некими специальными пакетами «моментами», но и простыми кумулятивными обновлениями. Расскажу о том, какие веховые обновления приносили нововведения в ОС (очевидно, что все последующие включают в себя все предшествующее). Ну и чтобы сделать заметку окончательно нечитаемой для рядового пользователя, но, чтобы энтузиасты как раз таки дочитали ее до конца, расскажу, как задействовать новый функционал в Windows 10 и Windows 11, который Microsoft еще автоматом не сделал общедоступным. И что самое важное, расскажу, как отключить новый функционал, если вы предпочитаете классическую реализацию (если такая бинарно еще сохранилась в ОС). Ну что, поехали?

Что такое Docs as Code классно описано в статье Docs as Code: введение в предмет.
В двух словах: это ведение документации на языке разметки (Markdown, AsciiDoc) с хранением в репозитории.
Плюшки — все вытекающие от работы с репозиторием.
Минусы — в этой статье.

На осенних Analyst Days прошлого года добрая четверть докладов была посвящена теме Docs as Code. На тот момент конклав аналитиков на моём прежнем месте работы уже 9 месяцев решал, нужен ли на проекте модный-стильный-молодёжный Docs as Code или всё же остаться в дышащем на ладан Confluence. К чему пришли — не знаю. На новом месте работы мы внедрили Docs as Code за неделю — было чёткое понимание проблематики, подход казался выигрышным решением. Используем полгода.

Привет!

Меня зовут Андрей и я руковожу IT-подразделением. Около 5 последних лет я работаю в Яндексе с командами от единиц до сотен инженеров. Так сложилось, что команд я потрогал много и разных: некоторых руководителей от времени перемещают по частям компании и зонам ответственности и я – не исключение.

За свой не самый продолжительный, но очень интенсивный карьерный трек я увидел большое количество разных управленцев. Часть – я вырастил из своих ребят до уровней M1 и M2 (руководителей групп и служб). Часть – нанял. Часть – достались мне в наследство.

Мы вместе с моими подчинёнными и руководителями наступали на множество граблей: ошибки найма, увольнения, ошибки делегирования, ошибки планирования, ошибки проектирования, ошибки в организации вечеринок и..подставь сюда любую приходящую тебе в голову.

Я хочу поделиться с читателем (предположительно – начинающим или уже опытным руководителем) школой мысли, которая снижает вероятность большинства известных мне видов ошибок. Фреймворк – очень простой концептуально и широко применимый. Я был бы рад, получив его в начале своего карьерного пути и буду счастлив, если эта статья поможет хотя бы одному руководителю стать лучше.

Ну что, поехали?

Всем привет! В этой статье я поделюсь четвёртым выпуском рубрики Открытый микрофон, в котором Иван Хахарев, ведущий аналитик Департамента системного анализа в Спортмастере, выступил с докладом про то, как создать службу поддержки, которая ляжет на большинство систем. Такая разработка может помочь проанализировать продукт, улучшить UX или даже провести реинжиниринг. 

Мы подобрали экспертов, которые делятся своей экспертизой и мнением, их комментарии - ниже по тексту. 

Приходите в комментарии, задавайте вопросы или делитесь своей экспертизой! 

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

Меня зовут Дмитрий Семин, я руковожу службой сопровождения клиентов в ITGLOBAL.COM. В этом материале расскажу, как устроена наша служба, сколько обращений обычно поступает от клиентов и систем мониторинга и кто их обрабатывает.

Продолжаю цикл статей про SLA, публикуя то, что не уместилось в основную статью Как написать хороший SLA.

Не секрет, что начиная с определённого уровня зрелости в ИТ компании начинают регистрировать запросы в специальных системах, трекерах. Это позволяет понимать, кто и чем занимается, анализировать текущую ситуацию и уже проделанную работу и ещё массу полезного — при правильной постановке дела выгоды заметно перевешивают бюрократию. Очерёдность исполнения запросов регулируется приоритетами.

За много-много лет работы в поддержке самых разных ИТ-систем, мне очень понравилась система из четырёх приоритетов, о которой речь и пойдёт ниже. Эта система настолько хорошо показала себя на практике в самых разных проектах, что я искренне удивляюсь, встречаясь с другими подходами к приоритетам. Так что я готов приложить определённое количество усилий для популяризации таких определений приоритетов. Чтобы они чаще всеми использовались и чаще встречались в жизни.

Крупными и опытными командами получена неумолимая статистика:

Не более четверти времени команды идет на процесс разработки. А, что еще хуже, существенная доля времени - от 5 до 15% и вовсе не связана с производственным процессом.

В этой статье мы собрали для вас ключевые аспекты, уделяя внимание которым вы сможете существенно увеличить производительность IT-команды. За счет чего? В первую очередь за счет устранения помех в работе.

Технологическая индустрия, СМИ, якобы независимые эксперты, как правило, рекомендуют покупать самые новые, самые продвинутые гаджеты: смартфоны, телевизоры, ноутбуки. А что делать, если обновиться нужно, а денег на топовое устройство нет? Ну, или просто не хочется тратить слишком много денег.

Брать новое дешёвое устройство? Такой себе вариант. Вполне вероятно, что хороший подержанный ноутбук сможет закрыть ваши задачи лучше. Если его немного подшаманить.

В какой-то момент у меня возникла необходимость разобраться с простыми SSH-туннелями: как из запускать и какие туннели могут помочь мне (обычному web-разработчику). Разобраться в этом удалось и я решил поделиться пояснениями в простой понятной форме.

Привет! Меня зовут Савр, я работаю инженером технической поддержки Arenadata. В прошлом году нам, как и многим другим компаниям, использовавшим зарубежное ПО, пришлось переходить на российские аналоги. В частности, с болью в сердце мы отказались от Jira Service Management (далее SM) — нашей системы управления обращениями заказчиков и основного инструмента службы поддержки. Мы были вынуждены перейти на российскую разработку SimpleOne.

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

Компания у нас на full-remote, поэтому заседание кружка параноиков мы проводим как-то так. Иногда под банджо в углу.

В жизни любого проекта наступает катастрофа. Мы не можем заранее знать, что именно это будет - короткое замыкание в серверной, инженер, дропнувший центральную БД или нашествие бобров. Тем не менее, оно обязательно случится, причем по предельно идиотской причине.

Насчет бобров, я, кстати, не шутил. В Канаде они перегрызли кабель и оставили целый район Tumbler Ridge без оптоволоконной связи. Причем, животные, как мне кажется, делают все для того, чтобы внезапно лишить вас доступа к вашим ресурсам:

Макаки жуют провода. Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца. Акулы жуют трансатлантические кабели Google. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.

Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan я сегодня вам и расскажу.

Уверен, вы слышали, что требования к разрабатываемому ПО должны быть S.M.A.R.T. - Specific (конкретные), Measurable (измеримые), Attainable (достижимые), Relevant (значимые) и Time-bound (своевременные). Слышали это правило все, но часто ли мы соблюдаем его? Часто ли проверяем требования по этим критериям? Если нет – мало обжигались. Давайте пофантазируем с примерами: «Что, если…»

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!

Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

Эта статья является попыткой обобщить имеющийся опыт, а также на неё я собираюсь ссылаться, когда меня будут в дальнейшем спрашивать, как должен выглядеть SLA. Работая в индустрии не первый десяток лет, я к своему удивлению регулярно сталкиваюсь с серьёзным непониманием основ, на которых строится SLA. Наверное, потому что документ довольно экзотический. После прочтения данного текста, я надеюсь, у вдумчивого читателя точечки над ё должны встать на свои места. Целевая аудитория — те, кто пишет SLA, и им сочувствующие.

В 2024 г. Java никуда не делась и в ближайшие много лет явно не исчезнет. Язык продолжает развиваться. ПО, написанного на этом ЯП, всё больше. Разработчиков тоже нужно много и сразу, причём хороших. Для того чтобы стать таким специалистом, нужно, конечно, учиться и практиковаться. Сильно помогают книги, о которых сегодня и поговорим. Под катом — подборка пособий по Java.

1. Недостаток хороших специалистов.
2. Небольшой поток, то есть сложно закладываться под редкие случаи.
3. Меньше доходы населения.
4. Ниже культура профилактики.
5. Ниже уровень понимания, как работает медицина (в т. ч. из-за всех перечисленных проблем, включая реальные доходы).