Рубрика «sla»
Как мы мигрировали в облако… пепла
2022-02-22 в 3:59, admin, рубрики: backup, devops, disaster recovery, kubernetes, kubertenes, OVH, OVHcloud, sla, информационная безопасность, пожар, резервное копирование, сгорелВаня, привет! У меня хорошая и плохая новость, как у вас говорят. Мы нашу миграцию в облако, похоже, сегодня закончим.
Такой вот звонок ко мне пришел от нашего VP of Engineering Виктора около 7 вечера 9 марта прошлого года. Дело в том, что Виктор знает русский, но никогда не жил в России, поэтому он часто добавляет "как у вас говорят" или какие-то другие только ему ведомые присказки, поговорки и пословицы. Но сейчас не об этом.
Почему у нас такое жёсткое лицензионное соглашение
2021-08-03 в 11:00, admin, рубрики: ruvds_статьи, sla, Блог компании RUVDS.com, Законодательство в IT, лицензии MS, лицензионное соглашение, управление проектами, хостинг, цод
Первый конфликт — в том, чтобы дать клиентам хостинга максимально хорошие условия, с одной стороны, но при этом помнить, что любая виртуальная среда — это коммунальная квартира. И сервер у нескольких виртуальных машин общий, поэтому нужны правила общежития. Решение такое: если гадит кто-то один — нужно его выселять, чтобы не было плохо остальным. Дальше нужно определить в соглашении, что именно хорошо, а что — плохо.
Второй конфликт — что делать, если вдруг выйдет из строя ЦОД или сработает какой-то другой крупный риск. Хостинг закупает услуги ЦОДа и отвечать за них не может, но при этом клиенту поставляется услуга, которая напрямую зависит от того, что там происходит. Мы компенсируем свои косяки, но у нас среди клиентов есть банки и страховые, а у них — очень хорошие юристы. Поэтому, если ЦОД упадёт, мы можем нарваться на многомиллионный риск за убытки бизнесу, которым не можем управлять. Здесь решение — страховать всю ответственность перед клиентом за падения, взломы, утечки данных и так далее в международной страховой компании.
Третий конфликт — лицензии MS, про что я уже писал в прошлый раз, когда касался пиратов. MS хочет иметь доступ к виртуальной машине со своим софтом 24/7, а в российской юрисдикции ВМ начиная от уровня гостевой ОС полностью закрыта для хостера. В итоге появляется костыль с аудитами по заявлениям о пиратстве — его мы разберём ещё раз. Читать полностью »
Как Лёха стал инженером по SRE: выдуманная история про невыдуманные проблемы
2020-11-06 в 13:16, admin, рубрики: devops, kubernetes, site reliability engineer, site reliability engineering, sla, slo, sre, Блог компании Southbridge, карьера за границей, системное администрирование, управление разработкойНаправление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.
Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).
Экспресс UV лампа своими руками 400-405 нм для полимеризации 3D фотополимерных моделей
2020-02-15 в 22:45, admin, рубрики: 3D-печать, 3d-принтер, 3dlcd, 3dprinter, 400nm, 405nm, anycubic, lcd 3d, photon3d, sla, UV, uv 400, uv 405, uvlamp, uvled, уф сушка, уф-светодиод, фотоотверждение, фотополимер, фотополимеризация, фотополимерный 3d принтерДоброго дня!
Речь пойдет о решении такой проблемы, как полимеризация готовых 3D моделей после печати на LCD 3D принтерах, например как на нашем — Anycubic Photon S. Этот принтер печатает на базе фотополимерной смолы — после распечатки модели моются в изопропиловом спирте, но сами модели остаются липкими, мягкими.
Предпосылкой написания явилась острая и быстрая необходимость в лампе для отверждения распечатанных моделей перед покраской. Анализ интернета показал отсутствие в продаже готовых бюджетных ламп — странно, при такой распространённости 3Д принтеров сейчас…
В любом случае, надеюсь статья будет полезна тем, кто начинает печатать на фотополимере и столкнулся с проблемой сушки напечатанных моделей.
Поехали
По инструкции от смолы — отвердителем для нее является УФ свет длиной волны 400-405нм.
Проверенным решением было бы купить к принтеру, его фирменную сушилку, но цена совсем не понятная — при бюджете принтера в 32 тысячи рублей, платить еще 23 за коробку со светодиодами какое то барство.
Решение — сколхозить лампу своими руками из доступных компонентов.
Читать полностью »
Слёрм SRE. Сплошной эксперимент c экспертами из Booking.com и Google.com
2020-02-06 в 9:43, admin, рубрики: capacity planning, Cascading Failures, ddos, devops, elastic, Error budget, gitlab, Grafana, kubernetes, prometheus, sla, sli, slo, sre, Блог компании Southbridge, интенсив, конференции, конференция, мероприятие, Слёрм, Управление продуктом, управление проектамиНаша команда любит эксперименты. Каждый Слёрм — это не статичное повторение предыдущих, а осмысление опыта и переход от хорошего к лучшему. Но со Слёрмом SRE мы решили применить абсолютно новый формат — дать участникам условия, максимально приближённые к «боевым».
Если кратко обрисовать, чем мы занимались на интенсиве: «Строим, ломаем, чиним,
изучаем». SRE мало чего стоит в голой теории — только практика, реальные решения, реальные проблемы.
Участники были поделены на команды, чтобы бодрый соревновательный дух не дал никому заснуть или запустить «Angry Birds» на iPhone по примеру Дмитрия Анатольевича.
Проблемы, глюки, баги и задачи обеспечивали участникам четыре ментора. Иван Круглов, Principal Developer в Booking.com (Нидерланды). Бен Тайлер, Principal Developer в Booking.com (США). Эдуард Медведев, CTO в Tungsten Labs (Германия). Евгений Варавва, разработчик широкого профиля в Google (Сан-Франциско).
Да ещё и участники поделены на команды — и соревнуются друг с другом. Интересно?
Иван, Бен, Эдуард и Евгений с добрым ленинским прищуром смотрят на бедных участников Слёрм SRE перед началом соревнования.
HighLoad++, Евгений Кузовлев (EcommPay IT): что делать, когда минута простоя стоит $100000
2020-01-21 в 16:26, admin, рубрики: big data, deploy, highload, redundancy, sla, Блог компании ua-hosting.company, конференции, хостингВсе рассказывают про процессы разработки и тестирования, обучения персонала, повышение мотивации, но этих процессов мало, когда минута простоя сервиса стоит космических денег. Что делать, когда вы проводите финансовые транзакции под жесткий SLA? Как повысить надежность и отказоустойчивость ваших систем, вынося за скобки разработку и тестирование?
Следующая конференция HighLoad++ пройдет 6 и 7 апреля 2020 года в Санкт-Петербурге. Подробности и билеты по ссылке. 9 ноября, 18:00. HighLoad++ Moscow 2018, зал «Дели + Калькутта». Тезисы и презентация.Читать полностью »
Хватит думать, что SLA вас спасет. Оно нужно, чтобы успокоить и создать ложное чувство безопасности
2019-09-26 в 13:42, admin, рубрики: sla, Блог компании Дата-центр «Миран», дата-центр Миран, дата-центры, Серверное администрирование, Сетевое оборудование, системы, хостинг
SLA, оно же «service-level agreement» —соглашение-гарантия между заказчиком и поставщиком услуг о том, что получит клиент в плане обслуживания. Также в нем оговариваются компенсации в случае простоев по вине поставщика и так далее. По сути SLA — это верительная грамота, с помощью которой дата-центр или хостинг-провайдер убеждает потенциального клиента в том, что он будет всячески обласкан и вообще. Вопрос в том, что в SLA можно написать все что угодно, да и события, прописанные в этом документе, наступают не слишком часто. SLA — это далеко не ориентир в подборе дата-центра и надеяться на него уж точно не стоит.
Все мы привыкли подписывать какие-то договоры, которые возлагают определенные обязательства. Не исключением является и SLA — обычно самый оторванный от реалий документ, который можно вообразить. Более бесполезен, наверное, только NDA в юрисдикциях, где понятия «коммерческой тайны» толком не существует. А вся проблема в том, что SLA никак не помогает клиенту в правильном выборе поставщика, а только пускает пыль в глаза.
Что чаще всего пишут в публичной версии SLA хостеры, которую показывают публике? Ну, первой строкой идет такой термин, как «надежность» хостера — это обычно цифры от 98 до 99,999%. По сути, эти цифры — лишь красивая выдумка маркетологов. Когда-то, когда хостинг был молодым и дорогим, а облака только снились специалистам (как и широкополосный доступ для всех и каждого), показатель аптайма хостинга был крайне и крайне важен. Сейчас же, когда все поставщики используют плюс-минус одно и тоже оборудование, сидят на один и тех же магистральных сетях и предлагают одни и те же пакеты услуг, показатель аптайма абсолютно непоказателен.
Читать полностью »
Обновление ассортимента фотополимерных 3D-принтеров Anet
2019-07-03 в 9:57, admin, рубрики: 3d-принтер, anet, Anet N4, Anet N7, anet3d, dlp, DLP N4, resin, sla, фотополимерныйНовый достойный представитель фотополимерных 3D-принтеров, производства Anet3D.
Модель N4 продуманная, полностью собранная и готовая к работе «из коробки».
Shit happens. Яндекс удалил часть виртуальных машин в своем облаке
2019-05-16 в 23:43, admin, рубрики: devops, sla, Облачные вычисления, облачные сервисы, потеря данных, Серверное администрирование, яндекс.облако
Кадр из фильма Мстители: Война бесконечности
По сообщению пользователя dobrovolskiy 15 мая 2019 года в результате человеческой ошибки Яндекс удалил часть виртуальных машин в своем облаке.
Пользователь получил письмо от техподдержки Яндекса с таким текстом:
Сегодня мы проводили технические работы в Яндекс.Облаке. К сожалению, из-за человеческого фактора были удалены виртуальные машины пользователей в зоне ru-central1-c, которые хоть раз находились в статусе SUSPENDED. Мы сразу заметили ошибку и остановили удаление. Увы, некоторые ВМ и их boot-диски были удалены.
В результате пользователем были полностью потеряны некоторые продакшн-сервера. Бекапы у пострадавшего были, но часть данных всё равно утрачена безвозвратно. Обычно Яндекс компенсирует даун-тайм своих сервисов, согласно своей политике, но кто компенсирует потерю данных?
Читать полностью »