Специалист отрабатывает свои навыки на виртуальном тренажере

Когда на производстве случается несчастный случай — это трагедия. Но кроме трагедии это ещё простой производства (часто на миллионы рублей), проверки и комиссии. В общем, повышать безопасность чисто экономически выгодно.

Проблема производственной безопасности — это организация (процессы) и инструменты. Мы уже много лет занимаемся именно инструментами: у нас прекрасная видеоаналитика для контроля СИЗ, прохода в опасные зоны, есть носимые устройства для предупреждения (включая умную каску, которая даже страхует от наезда погрузчиком, вовремя предупреждая, оповещает о падениях диспетчера и умеет подсказывать пути эвакуации). Но всё это только одна часть вопроса: кроме наличия инструментов нужно ещё их правильно внедрить и правильно организовать процесс обеспечения безопасности в целом.

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

В прошлом году сделали пилотный проект по облачной диспетчеризации для одной из сети АЗС. 

Проект интересный по двум причинам. Во-первых, у заказчика уже был опыт с системой автоматизации и диспетчеризации всех обычных инженерных систем в “стекляшке”, но, прямо скажем, не самый удачный. Так что от нас потребовался апдейт. Во-вторых, мы все переделали сделали диспетчеризацию облачной, причем включили в нее еще и топливную автоматику. А это больше тысячи параметров - объем и уровень топлива в резервуаре, его температура, давление в топливном трубопроводе, жидкость и пары в купольной шахте, переполнение резервуара, низкий уровень топлива и многое другое. 

Вообще облачная диспетчеризация - хорошая штука для компаний, у которых есть не один, а несколько (а лучше - много), территориально распределенных объектов. Дальше я расскажу, почему. А заодно - о том, как мы реализовали этот конкретный проект. 

Привет, Хабр! 

4 февраля мы проводим онлайн-митап о найме в ИТ. Хотим поделиться с миром результатами исследования об изменениях в ИТ-найме, которое провели наши нанимающие менеджеры из команды департамента разработки ПО КРОК.  Для этого мы проанализировали  почти 500 технических интервью, которые провели за последние полгода. А еще один из нас отправился на секретную миссию и получил от крупнейших компаний 6 офферов после 6 собесов. 

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

Инсайтами и видео с митапа поделимся в блоге позже, а пока расскажем о программе. Кому лень читать после ката  —  регистрируйтесь тут.

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

Чтобы подрядчики с доступом к боевой системе и тестовому стенду не устроили что-то злонамеренное, нужен контроль либо на стороне подрядчика, либо на стороне заказчика. Про людей подрядчика заказчик ничего не знает: они не сидят у него в офисе, им нельзя дышать в затылок. Тяжело разобраться, кто и с какой задачей подключается.

Собственно, дальше мы начали внедрять систему защиты.

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

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

У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стране, а еще, разработчики КРОК и Группы НЛМК прежде не работали вместе.

Звучит как организационный ад, и это недалеко от истины. Но мы справились и теперь хотим поделиться опытом работы в объединенной команде Группы НЛМК и КРОК в масштабном проекте по развитию информационных сервисов службы продаж.

Помимо основной работы в ИТ-компании КРОК, я также веду кружок спортивного программирования в вузе, у которого даже есть свой паблик. Так вот, порой ведешь блог, и кажется, что надо бы и аватарку красивую поставить, и как-то украсить страничку, картинки к постам в одном стиле запилить… но что-то все не получается, какое-то некрасивое все выходит, и вообще, что вы пристали, я программист! А нанимать профессионального дизайнера чтобы нарисовал дизайн систему для паблика из 50 человек… а вдруг не стрельнет, чем я ему платить буду?

К счастью, создать для своего бложика простую айдентику чисто “на первое время”, чтобы выглядеть “прилично” можно и без помощи дизайнера. Рассказываю как!

За последние 10 лет принципиальным образом так и не решились вопросы удобного и долговременного (или еще «архивного») хранения документов c электронной подписью (ЭП) и их обмена со взаимным доверием. Да, есть специальные «архивные» разновидности расширенных форматов ЭП (CAdES-A и XAdES-A), которые содержат несколько меток времени, списки отозванных сертификатов и цепочки удостоверяющих центров (УЦ) на момент формирования ЭП. Есть варианты решений с «переподписанием» документов с ЭП или созданием доверенной среды для их хранения. Однако все это не добавляет «юзабилити». Появились и новые проблемы: отсутствие единой политики применения квалифицированных сертификатов в коммерческих информационных системах (особенно на торговых площадках), из-за чего в сертификаты начали добавлять узкоспециализированные OID; отсутствие единого реестра выданных сертификатов при значительном увеличении их числа; большое количество УЦ и их «текучка»; попытки мошенничества с недвижимостью и налоговыми декларациями при помощи квалифицированных сертификатов с ЭП, полученных мошенническим образом.

Принятые 27 декабря 2019 г. изменения в Федеральный закон «Об электронной подписи» нацелены на то, чтобы, наконец-то, устранить большинство этих проблем, узаконить облачную ЭП, а также фактически перестроить рынок удостоверяющих центров. Закон также вводит новый институт – доверенную третью сторону (ДТС). Нормы о ДТС должны вступить в силу с 1 января 2021 года. Несмотря на это, почти все, что связано с ДТС, еще в ожидании разъяснений и регламентации со стороны регуляторов. Попробую описать подробно, что нас ждет.

В 2020 году многие компании переводили сотрудников на удалёнку. Далеко не всегда они оформляли это юридически правильно. Одно из типичных нарушений - отправить работника на удалёнку без его письменного согласия.Но знали ли вы, что все это время не было никакого правового статуса у удаленки в ТК РФ? 

В декабре Госдума приняла закон, который меняет правила удалённой работы. Новое регулирование вступает в силу с 1 января 2021 года. Больше нельзя будет снижать ЗП сотрудника из-за удалёнки, а для подписания большинства документов теперь не нужна электронная подпись. Об этих и других фактах читайте ниже. 

Хабр, привет! Меня зовут Ася, я ведущий инженер-тестировщик (QA Lead) в КРОК.

Недавно я отметила десятилетний юбилей в компании и в тестировании одновременно — да, за столько лет мне не надоело ни там, ни там. Хотя насчет тестирования было по-разному — успела даже дважды выгореть (один раз из-за декрета), стать контрол-фриком и влюбиться в профессию заново.

Про профессию тестировщика часто слышу, что это самый легкий и быстрый порог входа в ИТ — а там и на разработчика переучиться можно. Я же наоборот — училась на разработчика и даже успела им немного поработать, но душа к этому не лежала, потому что искать баги намного веселее. За всю мою карьеру я участвовала в совершенно разнообразных проектах: документооборот, файлообменники, статистические наблюдения, обработка обращений пассажиров в ЦППК, учет оборудования. А потом поняла, что этот опыт можно масштабировать на свою жизнь и даже на работу целого департамента. Так я стала агентом изменений департамента разработки программного обеспечения (ДРПО).

В этой статье хочу рассказать про свой путь и постараться ответить на вопрос, который мучает многих тестировщиков — а есть ли жизнь на Марсе задор и челленджи после многих лет в тестировании?

Склад запасных частей.

Примерно всё. Мы работаем практически со всеми поставщиками серверного железа, которые только встречаются в России: от редких «суперкомпьютеров» до «привезите нам ещё один Pentium II на завод, а то прошлый рассыпался от старости». Конечно, гораздо-гораздо чаще речь идёт про новое привычное железо, но и там обычно выбор из пяти-шести вендоров. И часто надо решить, с кем связать своё будущее узами законного брака поддержки и сервиса.

Разница в том, будет ли расти прайс на постгарантийную поддержку, нужно ли будет платить за день просрочки оплаты (часто — половину годовой цены штрафом), что будет при скачке курса доллара, евро или юаня, с каким именно специалистом вы будете иметь дело и так далее. Многие вещи можно обсудить и внести в договор «на берегу», если их предвидеть. Другие влияют на окончательную стоимость владения, поскольку означают незапланированные расходы. А многим это важно, потому что проект рассчитывается на несколько лет, и на него выделяется в бюджете фиксированная сумма.

Пройдусь по пунктам того, что неприятного может встретиться. Первая история такая: умер у заказчика как-то сервер, произведенный далеко в забугорье. Клиента попросили выслать этот процессор в центр обслуживания вендора. Месяц они его разглядывали, потом сказали: да, и правда, это процессор, и он сломался. Мы перечислим вам деньги, чтобы вы могли купить себе новый такой же сами.

Как вы представляете себе среднестатистического сотрудника поддержки? Нервный, задерганный, с красными глазами. Он разрывается между письмами в аутлуке, мессенджером и телефонными звонками. Всем в срочном порядке требуется его помощь. 

Сегодня я расскажу, как упростить жизнь ТП с помощью находчивости и современных технологий. Под катом — несколько готовых «рецептов», многие из которых можно внедрить в любой компании.

Что общего между Крымским мостом и СКС? Мы случайно выяснили: для железнодорожной части этого моста потребовалось 76 000 шпал. И примерно столько же оптических волокон в нашей СКС, построенной для банка «Открытие». Под катом рассказываю, как мы ее делали и тестировали (и даже немного о том, зачем на проекте понадобился маляр). 

«УРАЛХИМ» делает удобрения. № 1 в России — по производству аммиачной селитры, например, входит в топ-3 отечественных производителей аммиака, карбамида, азотных удобрений. Выпускаются серные кислоты, двух-трёхкомпонентные удобрения, фосфаты и многое другое. Это всё создаёт агрессивные среды, в которых выходят из строя датчики.

Мы строили Data Lake и заодно охотились на те датчики, которые замерзают, выходят из строя, начинают давать ложные данные и вообще ведут себя не так, как должны себя вести источники информации. А «фишка» в том, что невозможно строить матмодели и цифровые двойники на базе «плохих» данных: они просто не будут правильно решать задачу и давать бизнес-эффект.

Но современным производствам нужны Data Lake'и для дата-сайентистов. В 95 % случаев «сырые» данные никак не собираются, а учитываются только агрегаты в АСУТП, которые хранятся два месяца и сохраняются точки «изменения динамики» показателя, которые вычисляются специально заложенным алгоритмом, что для дата-сайентистов снижает качество данных, т. к., возможно, может пропустить «всплески» показателя… Собственно, примерно так и было на «УРАЛХИМЕ». Нужно было создать хранилище производственных данных, подцепиться к источникам в цехах и в MES/ERP-системах. В первую очередь это нужно для того, чтобы начать собирать историю для дата-сайенса. Во вторую очередь — чтобы дата-сайентисты имели площадку для своих расчётов и песочницу для проверки гипотез, а не нагружали ту же самую, где крутится АСУ ТП. Дата-сайентисты пробовали сделать анализ имеющихся данных, но этого не хватило. Данные хранились прореженные, с потерями, часто неконсистентные с датчиком. Взять датасет быстро не было возможности, и работать с ним тоже было особо негде.

Теперь вернёмся к тому, что делать, если датчик «гонит».

Привет, Хабр! Я Маша, старший инженер-разработчик iOS в КРОК и аспирант на кафедре Прикладной математики и Искусственного интеллекта в московском вузе. А еще я уже четыре года преподаю. Два года назад мы с коллегами с кафедры, преимущественно аспирантами, основали кружок спортивного программирования, который вырос в большое IT-коммьюнити в стенах универа, где мы делимся разного рода знаниями со студентами.

В рамках этой затеи мы решили улучшить процессы обучения дисциплинам Computer Science (до чего дотянулись). К нему у всех уже было много вопросов.

Первый ужас я испытала на первом же занятии со студентами. Одна группа не могла привести ДНФ в КНФ, другая — не смогла даже общим усилием воли вспомнить таблицу истинности для конъюнкции и дизъюнкции. Третья — не понимала как программно устроены списки (это у нас проходят годом ранее). А потом я вспомнила себя — про мой курс преподы говорили то же самое. И про курсы до нас, и про курсы после меня. И школьную учительницу Ольгу Николаевну вспомнила: «В этом году класс еще слабее, чем в прошлом — если так пойдет и дальше, вернемся к жизни на деревьях!». В школе мне казалось, что это такой изощренный педагогический прием, который должен подхлестнуть нас учиться усерднее чтобы «доказать, что мы лучше чем кажется». Ошибалась.

Решили мы с коллегами порефлексировать — а почему так происходит? Результаты, наши грабли и опасные эксперименты с тигром под катом!

Этот модульный ЦОД мы построили меньше, чем за три месяца. В первых числах ноября начали монтаж на площадке, а в конце декабря уже сдали его в эксплуатацию. 

В общих чертах запрос от заказчика именно таким и был: очень быстро нарастить вычислительные мощности под свой ИТ-проект там, где дополнительного места совсем нет. Решено было построить модульный ЦОД. И сделать это недорого. Спустя год готов рассказать, как это было. Как мы делали полную предварительную сборку и разборку ЦОДа на площадке в Сибири. Как поливали его водой из мойки “Керхер” и разогревали, как духовку. 

Заодно поделюсь нашим опытом обхода граблей при строительстве модульных дата-центров. А также расскажу о некоторых граблях, на которые мы все-таки наступили, но в каске.

Служба техподдержки в крупной компании обычно обслуживает целый зоопарк сервисов, например: пару виртуальных АТС, онлайн-магазин, умный дом и охранную систему в придачу. У ребят всегда есть работа — тысячи звонков с сотнями проблем от подключения новых телефонных номеров, до отвалившихся IP-камер.

Чтобы упростить работу техподдержки, команда из нашего акселератора разработала автоматизированную систему на базе машинного обучения. Она запускается за 2 дня без подготовки и без помощи специалистов по data science. Подробности под катом.

The words is just awesome (Discovery Channel, 2009)

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

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

Я занимаюсь сервисным обслуживанием контакт-центров клиентов в КРОК. И подобных историй за время карантина (да и без него) случалось немало. Чем все закончилось и как мы перевели на удаленку несколько десятков контактных центров, расскажу под катом.

Судя по числу вопросов, которые нам стали прилетать по SD-WAN, технология начала основательно приживаться в России. Вендоры, естественно, не дремлют и предлагают свои концепции, а некоторые смельчаки первопроходцы уже внедряют их у себя на сети.

Мы работаем почти со всеми вендорами, и за несколько лет в нашей лаборатории я успел покопаться в архитектуре каждого крупного разработчика программно-определяемых решений. Немного особняком тут стоит SD-WAN от Fortinet, который просто встроил функционал балансировки трафика между каналами связи в софт межсетевых экранов. Решение скорее демократичное, поэтому к нему обычно присматриваются в компаниях, где пока не готовы к глобальным переменам, но хотят эффективнее использовать свои каналы связи.

В этой статье я хочу рассказать, как настраивать и работать с SD-WAN от Fortinet, кому подойдет это решение и с какими подводными камнями здесь можно столкнуться.

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

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

Собственно, первое, что вы видите в стойке — это ручки с названием модели, за которые можно и нужно дёргать контроллеры из массива.



Делается это без выключения, наживую, и запас производительности такой, чтобы банковские системы не тормозили во время замены. Чтобы так получилось, понадобилось написать собственную файловую систему (точнее, аналог RAID), собрать внутри кластер и сделать ещё пару улучшений, заодно выкидывая оверхед, доставшийся от жёстких дисков.

Давайте посмотрим, что получилось и как получилось. Начнём с архитектуры.

Для начала — процедура работы с массивом не предусматривает кнопок питания. Совсем. Не понадобится. Для выключения достаточно просто выдернуть кабели из PDU.

Привет, Хабр! Наверное, у каждого из нас есть такой файлик, куда мы припрятываем что-то полезное и интересное для себя. Какие-то ссылки на статьи, книги, репозитории, мануалы. Это могут быть закладки в браузере или даже просто открытые вкладки, оставленные на потом. Со временем все это разбухает, ссылки перестают открываться, а большая часть материалов просто устаревает.

А что если поделиться этой годнотой с сообществом и выложить этот файлик на гитхаб? Тогда ваши труды могут быть полезны еще кому-нибудь, а поддерживать актуальность можно совместно, принимая обновления от желающих через старые добрые PR'ы. Именно для этого предназначен проект Awesome lists. Он входит в ТОП-10 репозиториев гитхаба, обладает 138К звезд, и ссылка на ваши труды может оказаться прямо в его корневом README, что привлечет огромную аудиторию к вашему творчеству. Правда, для этого придется немного постараться. О моем опыте таких стараний хочу поделиться с вами.

Меня зовут Максим Грамин. В КРОК занимаюсь Java-разработкой и исследованиями в области БД. В этом посте я расскажу, что такое Awesome Lists и как сделать свой настоящий официальный awesome-репо.