Не так давно фотополимерная печать была дорога и доступна только профессионалам.
Сейчас стоимость оборудования резко снизилась за счет известных стартапов и массово производимых настольных (офисных) 3D принтеров из Поднебесной.
Предлагаю вашему вниманию три популярных модели для домашнего использования (цены от $229).
Читать полностью »
Человек – главная ценность любого предприятия. Успех всего дела зависит от того, как люди коммуницируют между собой, как вместе добиваются поставленных целей, от командной работы. Постоянное оттачивание навыков, процессов и инструментов позволяет работать эффективней.
Мы в Маркете работаем над тем, чтобы как можно быстрее доставлять новые возможности нашим пользователям. Для этого мы постоянно изучаем наши процессы и оптимизируем все этапы работы над задачей. Сегодня мы расскажем читателям Хабра об оптимизации одного из них, а именно процесса код-ревью.
Для начала надо представить, какой флоу в разработке у нас принят:
![[КЕЙС] SLA 3D-печать на заводе судовой электроники - 1](https://www.pvsm.ru/images/2018/06/26/keis-SLA-3D-pechat-na-zavode-sudovoi-elektroniki.jpeg "[КЕЙС] SLA 3D-печать на заводе судовой электроники - 1")
Мы поставили 3D принтер iSLA-450 Pro на «Завод имени А.А.Кулакова», который специализируется на выпуске слаботочного оборудования и систем автоматизации, управления и защиты информации для кораблей и судов разных классов.
Продукция завода обеспечивает безопасное и эффективное судовождение всех типов судов по всем морям планеты.
Читать полностью »
DWS Systems — итальянский производитель фотополимерных 3D-принтеров для ювелиров, стоматологии и промышленного прототипирования. В ассортименте компании как настольные, так и крупногабаритные модели, сегодня — о линейке XFAB, относящейся к первой категории.
Читать полностью »
Здравствуйте! Представляем вам таблицу испытаний фотополимерных материалов разных производителей с 3D-принтерами компании Formlabs — Form 1+ и Form 2.
Читать полностью »
В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.
Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.
Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!
Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.
Рано или поздно при организации технической поддержки в более или менее крупной организации приходится иметь дело вот с этим: с SLA.
И тут возникает ряд задач, успешно решив которые можно сильно упростить себе жизнь.
Итак предположим, что в нашей организации есть следующие подразделения, помимо ИТ:
Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.
Эта статья является попыткой обобщить имеющийся опыт, а также на неё я собираюсь ссылаться, когда меня будут в дальнейшем спрашивать, как должен выглядеть SLA. Работая в индустрии не первый десяток лет, я к своему удивлению регулярно сталкиваюсь с серьёзным непониманием основ, на которых строится SLA. Наверное, потому что документ довольно экзотический. После прочтения данного текста, я надеюсь, у вдумчивого читателя точечки над ё должны встать на свои места. Целевая аудитория — те, кто пишет SLA, и им сочувствующие.
Ниже сплошной текст без диалогов и картинок.Читать полностью »
Сегодня хочу поговорить о том, как читать Service Level Agreement в договоре на облачные сервисы. SLA – это норма: клиенты требуют его на этапе запроса, провайдеры указывают заветные девятки во всех материалах. Отрицать не буду – без SLA плохо, но какие зоны ответственности затрагивает соглашение, не всегда понятно. Попробуем разобраться, что же это такое и когда бежать к провайдеру, размахивая договоров, а когда искать проблему на месте.
Простой пример: у клиента перестает работать ВМ, клиент сразу думает, что проблема в инфраструктуре. И смотрит, что же там в SLA по поводу доступности. А может, на самом деле зависла ОС, клиентская сеть лагает, — предположить можно всё что угодно. Если проблема внутри ОС, то провайдер ресурсов тут не поможет.
