Что такое пси разработка
Объявления
Если вы интересуетесь релейной защитой и реле, то подписывайтесь на мой канал
ПМИ и ПСИ
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Сообщений 10
1 Тема от BenGan 2013-08-28 08:06:16
Тема: ПМИ и ПСИ
2 Ответ от Yuriy82 2013-08-28 08:21:24
Re: ПМИ и ПСИ
3 Ответ от BenGan 2013-08-30 12:46:35
Re: ПМИ и ПСИ
4 Ответ от _vlad 2013-09-09 13:56:21
Re: ПМИ и ПСИ
Коллеги, немного заблуждаетесь.
Стадии сдачи заказчику:
1. Заводская приемка (Заводские ПСИ).
2. Приемка в опытную эксплуатацию.
3. Приемка в пром. эксплуатацию.
5 Ответ от BenGan 2013-09-11 07:16:27 (2013-09-11 07:18:51 отредактировано BenGan)
Re: ПМИ и ПСИ
Теперь осталось понять, что описывается в ПМИ, все три стадии:
1. Заводская приемка (Заводские ПСИ).
2. Приемка в опытную эксплуатацию.
3. Приемка в пром. эксплуатацию.
или только последние две, или на каждую стадию своя ПМИ?
6 Ответ от Yuriy82 2013-09-11 09:11:16
Re: ПМИ и ПСИ
На каждый вид испытаний свое ПМИ. Вы же когда собираетесь испытывать что-то, должны представлять как именно и что вы испытываете, вот это и пишется в ПМИ.
Содержание документов на системы автоматизации, как правило регламентируются ГОСТ 34
Если интересуют ПМИ для объектов ФСК, то на сайте ФСК должны быть типовые ПМИ.
7 Ответ от BenGan 2013-09-12 11:04:08
Re: ПМИ и ПСИ
Теперь понятно, Спасибо!
8 Ответ от lik 2013-09-12 12:13:41
Re: ПМИ и ПСИ
9 Ответ от last_hero 2014-01-10 10:59:58
Re: ПМИ и ПСИ
Нет коллега протокол вам могут выдать на шкаф или на конкретный терминал, а вот испытания системы в целом (сеть, шторма и прочее) это уже ПМИ. По крайней мере я так всегда делаю на терминалы, шкафы, интеграции по цифре оформляются протоколы, после чего проводятся комплексные испытания.
10 Ответ от TapakaH 2015-01-30 16:32:49
Re: ПМИ и ПСИ
Сообщений 10
Тему читают: 1 гость
Чтобы отправить ответ, вы должны войти или зарегистрироваться
приемо-сдаточные испытания
3.16 приемо-сдаточные испытания: По ГОСТ 16504.
3.8.2 приемо-сдаточные испытания: Испытания, которым подвергают каждый образец изделия в течение или после изготовления с целью установления соответствия его определенным требованиям.
3.29 приемо-сдаточные испытания (routine test): Испытания, которым подвергают отдельное устройство в течение и/или после изготовления, с целью установления соответствия устройства определенному критерию.
3.9.2 приемо-сдаточные испытания (МЭС 151-04-16) [3]: Испытание, которому подвергается каждый образец изделия в течение или после изготовления с целью установления соответствия его определенным требованиям.
47. Приемо-сдаточные испытания *
F. Essais de réception
Контрольные испытания продукции при приемочном контроле
3.19 приемо-сдаточные испытания (routine test): Испытания, которым подвергается каждое отдельное устройство (оборудование) во время изготовления или после него, с тем чтобы убедиться, что оно соответствует определенным критериям (Международный электротехнический словарь 151-04-16, измененная редакция) [1].
3.31 приемо-сдаточные испытания: Контрольные испытания продукции при приемочном контроле (ГОСТ 16504-81).
3.9 приемо-сдаточные испытания: Контрольные испытания труб на соответствие требованиям стандарта при приемочном контроле на предприятии-изготовителе.
приемо-сдаточные испытания: Контрольные испытания продукции при приемочном контроле.
3.7.2 приемо-сдаточные испытания (routine test): Испытание, которому подвергается каждый образец АВДТ в течение или после изготовления с целью установления его соответствия определенным критериям.
[МЭК 60050 (426-53-02), модифицированный]
приемо-сдаточные испытания: По ГОСТ 16504;
3.29 приемо-сдаточные испытания: Контрольные испытания продукции при приемочном контроле.
3.1 приемо-сдаточные испытания: Испытания, выполняемые для проверки качества изготовления двигателя, а также подтверждения выполнения требований, установленных по согласованию между потребителем (заказчиком) и изготовителем.
приемо-сдаточные испытания: Контрольные испытания продукции при приемочном контроле.
3.2.1 приемо-сдаточные испытания (routine tests): Испытания, проводимые изготовителем на каждой строительной длине кабеля или на каждом виде арматуры с целью проверки соответствия установленным требованиям.
3.23 приемо-сдаточные испытания: Контрольные испытания продукции при приемочном контроле.
3.9.2 приемо-сдаточные испытания: Испытание, которому подвергается каждый образец АВДТ в течение или после изготовления с целью установления его соответствия определенным критериям.
6.2 Приемо-сдаточные испытания
6.2.2 Состав испытаний и последовательность их проведения в пределах каждой группы должны соответствовать указанным в таблице 19.
6.2.3 Испытания по группе С-1 проводят по плану выборочного одноступенчатого контроля с приемочным числом С = 0.
Объем выборки составляет 10 % от сдаваемой партии, но не менее трех барабанов с кабелем. Выборку составляют случайным отбором.
Допускается по группе С-1 проводить испытания по плану сплошного контроля в процессе производства.
Вид испытания или проверки
Проверка конструкции и конструктивных размеров
3.2.1-3.2.4, 3.2.6, п. 4.1.1.1-4.1.1.9, 4.1.1.12-4.1.1.18
Проверка отсутствия обрывов жил, контактной проволоки, экрана, троса и контактов между жилами, между жилами и экраном, экраном и броней
Проверка герметичности изоляции
Проверка герметичности пластмассовой оболочки и защитного шланга
Проверка алюминиевой оболочки
Проверка защитных покровов
Определение электрического сопротивления токопроводящих жил
Определение электрического сопротивления изоляции
Проверка электрической емкости рабочих пар
Проверка наличия избыточного давления в кабеле с числом пар 100 и более
Проверка маркировки и упаковки
Проверку герметичности изоляции (4.1.1.2) проводят в процессе производства до скрутки изолированных жил в пару.
Допускается по группе С-3 проверку герметичности оболочки и шланга проводить по плану сплошного контроля в процессе производства.
6.2.4 Правила приемки кабелей в части защитных покровов (4.1.1.17) должны соответствовать ГОСТ 7006.
10. Приемо-сдаточные испытания
8.10 приёмо-сдаточные испытания
Контрольные испытания арматуры при приемочном контроле.
7.2 Приемо-сдаточные испытания
7.2.1 Приемо-сдаточным испытаниям на соответствие требованиям 3.2, 4.3-4.7, 4.9-4.11 и 6.2 подвергают каждую партию цепей. Объем партии цепей одного типоразмера типов ПР, 2ПР, 3ПР и 4ПР шага 25,4 мм и более не должен превышать 500 м. Объем партии цепей остальных типов и размеров устанавливает изготовитель, но он не должен превышать 1000 м.
7.2.2 Соединительные и переходные звенья должны предъявляться к испытаниям на соответствие требованиям 3.2, 4.3-4.5 и 4.9 партиями, состоящими не более чем из 2000 шт. соединительных и 1000 шт. переходных звеньев одного типоразмера.
7.2.3 В партию должны входить цепи одного типоразмера (одного обозначения), изготовленные из одинаковых материалов (марок) по одному технологическому процессу, на одном оборудовании.
7.2.4 Внешнему осмотру (4.4; 4.5) подвергают все производимые цепи.
7.2.5 Для проведения приемо-сдаточных испытаний методом случайной выборки отбирают от партии:
7.2.6 Для испытаний на разрушающую нагрузку (по 3.1) от партии соединительных и переходных звеньев отбирают звенья для комплектации двух комбинированных образцов по одному из следующих вариантов набора звеньев:
— три соединительных и четыре внутренних звена;
— два соединительных, два переходных и три внутренних звена;
— три соединительных, два двойных переходных и два внутренних звена;
— семь переходных звеньев.
Допускается увеличение длины испытываемых образцов.
7.2.7 При обнаружении несоответствия хотя бы одного параметра цепи, соединительного или переходного звена требованиям настоящего стандарта по этому параметру проводят повторные испытания удвоенного количества образцов. Результаты повторных испытаний являются окончательными и распространяются на всю партию изделий.
7.3 Потребитель имеет право контролировать качество цепей в объеме 7.2.1-7.2.6 методами, указанными в разделе 8 настоящего стандарта.
8.10 приемо-сдаточные испытания
Контрольные испытания арматуры при приемочном контроле.
Смотри также родственные термины:
3.6 приемо-сдаточные испытания (ПСИ): Контрольные испытания изготовленной продукции, по результатам которых принимается решение о ее пригодности к поставкам и (или) использованию.
14. Приемо-сдаточные испытания изоляции электрооборудования
3.30 приемо-сдаточные испытания партии нефти: Техническая операция, заключающаяся в определении показателей качества, при приемочном контроле партии нефти (с учетом ГОСТ 15.309, ГОСТ 16504).
3.27 Приемо-сдаточные испытания партии нефти: техническая операция, заключающаяся в определении показателей качества, при приемочном контроле партии нефти (с учетом ГОСТ 15.309, ГОСТ 16504).
4.2. Приемо-сдаточные испытания реле нормального специального исполнений
Этим испытаниям должно подвергаться каждое реле.
4.2.1. Испытание изоляции
4.2.1.1. Испытание на электрическую прочность проводится с изоляционной жидкостью и без нее. В соответствии с методами испытаний остальных электрических устройств системы контроля и управления трансформатором для реле допускаются следующие методы испытания, из которых в данном случае применяется только один:
напряжением переменного тока 2000 В, 50 Гц, прикладываемым толчком и выдерживаемым в течение 5 с;
напряжением переменного тока 2000 В, 50 Гц, плавно поднимаемым в течение 1 мин до указанной величины;
напряжением переменного тока 2500 В, 60 Гц, поднимаемым в течение 5 с до указанной величины.
4.2.1.2. Испытанию на электрическую прочность по указанным методам подвергаются:
при замкнутых контактах коммутационной трубки все контактные системы относительно друг друга при двухпоплавковом реле, нормального исполнения 1 относительно 3.
При двухпоплавковом реле с двухполюсной схемой 1.1 относительно 1.2 и 3; 1.2 относительно 3.
4.2.1.3. Электрическая прочность разомкнутых контактов внутри коммутационной трубки у каждой контактной системы испытывается следующим образам:
при однопоплавковом реле 1 относительно 2,
при двухпоплавковом реле нормального пополнения 1 относительно 2; 3 относительно 4,
при двухпоплавковом реле с двухполюсной схемой 1.1 относительно 2.1, 1.2. относительно 2.2, 3 относительно 4.
Изоляция считается выдержавшей испытание, если не было пробоя или перекрытия.
Примечание. Допускается проведение дополнительного испытания отдельных элементов реле с помощью мегомметра.
Изоляция считается выдержавшей испытание, если величина сопротивления изоляции составляет не менее 0,5 МОм.
4.2.2. Испытание на герметичность
Реле испытывается изоляционной жидкостью с температурой от плюс 70 до плюс 90 °С в течение 20 мин, при избыточном давлении 1 × 10 5 Па и считается выдержавшим испытание, если на поверхности не будет обнаружено следов изоляционной жидкости.
4.2.3. Испытание на работоспособность посредством испытательной кнопки
Реле наполняется изоляционной жидкостью с температурой от плюс 70 до плюс 90 °С и испытательную кнопку подвергают трехразовому нажатию. Реле считается выдержавшим испытание, если контактные системы три раза переключались безотказно, а у двухпоплавкового реле верхняя контактная система сработала первой.
4.2.4. Испытание на срабатывание контактных систем при скоплении газа
4.2.5. Испытание на срабатывание контактных систем при потере изоляционной жидкости
Реле считается выдержавшим испытание, если контактные системы переключаются безотказно.
4.2.6. Испытание на срабатывание контактных систем при потоке изоляционной жидкости можно проводить двумя методами.
4.2.6.1. Реле монтируется на испытательном стенде в номинальном положении и испытывается поочередно при всех порогах срабатывания. Посредством открытия трубопровода изоляционная жидкость с температурой от плюс 70 до плюс 90 °С, нарастание скорости которой настолько медленно, что позволяет произвести измерение мгновенной скорости, должна течь через реле. Реле считается выдержавшим испытание, если контактная система однопоплавкового реле или нижняя контактная система двухпоплавкового реле переключаются безотказно при достижении установленного порога срабатывания согласно п. 3.2.3.
4.2.6.2. Реле испытывается при верхнем значении допускаемого отклонения от установленного порога срабатывания и считается выдержавшим испытание, если контактные системы переключаются безотказно.
Реле испытывается при нижнем значении допускаемого отклонения от установленного порога срабатывания и считается выдержавшим испытание, если контактные системы не переключаются.
4.2.7. Проверка маркировки
Реле должно проверяться на маркировку согласно п. 5.1. Маркировку реле считают выполненной правильно, если на нем прикреплены заводской щиток, щиток с инструкцией по обслуживанию испытательной кнопки и схема присоединения контактных систем. На указанных щитках и схеме должны быть отчетливо нанесены необходимые технические данные. Кроме того, на корпусе и крышке должна быть красная стрелка.
DevOps в Сбербанк-Технологиях. Инструментальный стандарт
В этой статье пойдет речь об организации инструментального стека DevOps на примере Сбербанк-Технологий и ППРБ. Статья предназначена для инженеров по автоматизации инфраструктуры, которым необходима объективная оценка структуры работ по внедрению DevOps — и для всех, кто хочет ознакомиться с их работой.
Не секрет, что в маленькой сплоченной команде организовать DevOps-процесс весьма просто. Более того, у современных грамотных разработчиков и админов, такой процесс может сложиться сам собой — как результат высокой культуры разработки и поддержки. Но что делать, если твоя маленькая команда из десяти человек начинает расти до конторы из сотен людей? Что делать, если в твоей организации уже несколько тысяч человек, а девопсом и не пахло? С этими вопросами мы обратились к сотрудникам компании Сбербанк-Технологии, имеющей положительный опыт внедрения практик DevOps в крупномасштабных проектах, и кое-что узнали.
Safe Harbor
Во-первых, небольшая оговорка. Многие спрашивают, зачем нам читать статьи о том, как это сделано в других компаниях? Они сделали так, а мы сделаем эдак, какая разница-то.
Продукты Сбербанк-Технологий используются, конечно, в Сбербанке, и от стабильности и безопасности их работы зависят наши с вами деньги. Появление этой статьи в том числе показывает, что компания достигла того момента в своем развитии, когда о внутренних технологических процессах уже можно рассказывать, и это абсолютно нормально. Это не какая-то security through obscurity, а по-настоящему хорошая, качественная отлаженная система — в этом её ценность, и ценность текста, который вы сейчас читаете. Это — вещь, которая действительно работает. С этим знанием можно делать все что угодно — например, один в один скопипастить такую же инфраструктуру себе. Или пойти работать в Сбербанк-Технологии, если вам вдруг понравилось жить с такой инфраструктурой.
Тем не менее, внедрение девопса в промышленную эксплуатацию мы обсуждать все же не станем. Давайте сделаем вид, что это не только из-за безопасности, а еще и потому, что внедрение всё еще идет, и некорректно здесь обсуждать результаты неубитого медведя. Предполагается, что внедрение девопса ППРБ на пром произойдет уже в конце этого, либо начале следующего года — возможно, о нем расскажут на JBreak/JPoint 2018. Давайте сконцентрируемся на настоящем.
В любом случае, в статье могут быть ошибки и недочеты. Данная статья не является официальной позицией компании Сбербанк-Технологии или Сбербанка. Полученная из этой статьи информация не может использоваться как основание для принятия любых коммерческих и других важных решений.
Масштаб проблемы
В чем особенность девопс-проектов СБТ (давайте называть организацию таким неформальным образом)? Конечно, это масштаб. В 2017 году количество сотрудников СБТ превысило 9800 человек, расположенных в 17 городах России.
Зачем нужна эта уйма людей, чем они вообще занимаются? (спросит любой нормальный человек). Формально это звучит вот так:
Что это значит с точки зрения инженера-инфраструктурщика, который занимается внедрением девопса? Глядите, у нас обычно есть, как минимум, следующий набор задач, которые необходимо поставить и решить:
Каждый из этих вопросов резко осложняется от увеличения масштаба. Можно быстро договориться об инженерных практиках внутри своей команды, но помирить между собой 8500 человек, имеющих совершенно разные взгляды на разработку — это челленж. Обычной галере тут бы и лапки, но СБТ умеет превозмогать.
То, что кажется одной команде свободой (например, свободой использовать стандартизованный пайплайн, в рамках которого можно не задумываться о ненужных мелочах), для другой выглядит как существенное ограничение свободы выбора инструментов. На красивых маркетологических презентациях по девопсу не любят рассказывать, что если одна команда делает Единую Всеобщую Платформу Всего, то еще 100 команд будут ее ненавидеть за необходимость использования этой стандартной платформы, а не любимой Скалы и Хаскеля. С другой стороны, если всем дать возможность выбирать разнородные решения, никогда не выйдет общего продукта.
Недостаточно весело. Давайте добавим еще немного сложности! Дело в том, что проекты типа Технологического Ядра ППРБ (один из основных проектов в СБТ) — это черезвычайно сложные самописные технологии, специально предназначенные для особого, кастомного процесса развертывания. (Об этом будет ниже). По сути, это собственная Java-платформа, и как любят шутить разработчики “еще немного — и напишем собственную Java-машину!”. Даже базы данных тут особые — GridGain и набор уникальных ноу-хау на тему, как этот GridGain вообще готовить. Эта сложность является частью предметной области, нельзя просто так взять и сказать “а давайте все выбросим и перепишем на Golang в виде трех микросервисов”. Это так не работает!
Таким образом, инструментальный стек является точкой баланса не только между различными культурами, но и различными подходами к проектированию и программированию — бездонная пропасть между высокоспециализированным технологическим стеком и желанием иметь стабильный, десятилетиями оттестированный софт для админинстрирования.
Поэтому каждый элемент инструментального стандарта CI/CD СБТ — это компромиссное решение. Эти решения, как правила дорожного движения, написаны кровью и годами. Пришло время показать этот инструментальный стандарт!
Инструментальный стандарт CI/CD
И вот сейчас вы удивитесь. Удивитесь его обычности. Как удивились мы в JUG.ru впервые увидев это, так удивились и архитекторы-инфраструктурщики СБТ, когда поняли, что выходит в результате. Вы же привыкли, что СБТ постоянно пишет какие-то невообразимые новые фреймворки, используя их странными способами, чтобы потом рассказывать об этом на конференциях? Не в этот раз. Оказывается, самый лучший способ (на данный момент, осень 2017 года) — использовать то, что используют все, и заполировать решение до зеркального блеска.
Для начала, взгляд сверху:
Такая же последовательность шагов есть примерно у всех современных проектов. ПСИ — это Приемо-Сдаточные Испытания.
Заранее извиняемся, что картинка плохо читается на мобильниках. В дальнейшем все эти пункты будут продублированы большими пиктограммами, так что вы ничего не потеряете.
Для многих является шоком то, что кодирование — чуть ли не самая важная и жирная часть стандартов CI/CD. Дело в том, что если исходный софт написан критически неправильно, то ему уже никакой “девопс”, ничего не поможет.
По этому поводу существует два основополагающих элемента, зависящих от роли:
Разработчики могут использовать то, что нужно для выполнения задачи. В качестве стандарта для Java-разработки, например, лучше взять те средства, которые используют во всем мире: Maven (собственно Java), Node Package Manager (для JS-фронта), JUnit и TestNG (тестирование). СБТ не разрабатывает своих собственных систем сборки не потому, что не может (чем мы хуже Google?), а потому что это нарушило бы идею общей точки равновесия. Слишком многие внешние по отношению к компании проекты (попробуйте прожить без Spring Framework!) завязаны на стандартные утилиты вроде Maven, и нарушать эту интеграцию бессмысленно.
Хранение детальных требований на этом этапе происходит на Wiki-подобной системе (н-р Confluence). Работа с задачами происходит на основе стандартной аджайл-терминологии (эпик, фича, юзер-стори, итп), нативно реализованных в выбранной системе управления задачами (н-р JIRA). Наличие этих двух систем критически важно для получения хорошего результата. Это правило записано кровью — даже маленькому проекту нужно сразу же выдавать вики и багтрекер.
Важно отметить, что здесь и далее, для разработки используются два различных репозитория:
В рамках идеи Infrastructure as Code, сейчас зачастую принято хранить скрипты развертывания вместе с проектом в одном репозитории. В результате длительной практики, в СБТ выбрали иметь отдельный репозиторий для скриптов развертывания, и при необходимости осуществлять сильную связанность программным способом. Это особенность связана исключительно с масштабом и необходимостью сложных связанных обобщенных конфигураций, когда один и тот же “скрипт” может работать с разными продуктами. Плюс это позволяет развести команды разработки и администрирования по зонам ответственности и уровням доступа. Конкретные настройки проектов и специализированные скрипты, конечно, хранятся вместе с проектами.
В качестве управляющей системы здесь и далее используется Jenkins. Кому-то он может не нравиться, по причине того, что это древний софт, обросший определенным количеством легаси, и имеющим серьезный футпринт по объему оперативной памяти, использованию процессора, и так далее. Но помните что мы говорили про точку баланса? Факт остается фактом, что при всех своих недостатках, прямо сейчас (осень 2017 года), Jenkins — это именно та система, которую согласны использовать все. В будущем это, возможно, изменится.
Кроме Дженкинса используется дополнительная система управления сквозным процессом развертывания, начинающаяся с этапа кодирования, и продолжающаяся вплоть до ПРОМа. Но это специальный внутренний софт, описывать который в данной статье не имеет смысла не только по причине недоступности в Open Source, но и потому, что он очень заточен под конкретные особенности СБТ. Есть предположение, что любая компания с достаточно большим пайплайном всегда пишет подобную систему. Для небольших проектов она может существовать в рудиментарном виде, в виде пачки скриптов, не зависящих от Дженкинса. При масштабировании на 10+ проектов, идущих в связке, она может превратиться в серьезный софт.
Важно, что репозиторий скриптов развертывания, дженкинс и инструменты сквозного управления доступны сразу же, начиная с этапа кодирования. Если кому-то из разработчиков будет нужно пойти на Jenkins и сделать там новый джоб — это нормально. Использование девопс-инструментов — это нечто настолько же свободно доступное и неотъемлемое, как дышать воздухом.
У многих разработчиков есть собственные DEV-стенды (сервера), на которых они могут проводить простое системное тестирование и любые удобные эксперименты вне своего компьютера. Конечно, эти стенды очень ограничены в ресурсах (им экономически бессмысленно выделять терабайт RAM), и на них никак нельзя провести интеграционное тестирование. Но для экспериментов — пойдет.
На этом этапе происходит несколько ключевых вещей:
По поводу ИБ мы тут распространяться не будем по понятной причине. Последнего кто говорил о безопасности забрало НЛО 🙂 Достаточно сказать, что все элементы CI/CD учитывают требования безопасности, и в случае чего там мышь не проскочит. Обычно безопасность понижает удобство использования инструментов CI/CD, поэтому это очень сложная тема, наполненная особыми инженерными компромиссами.
У каждого проекта есть свой собственный стенд (сервер), на котором можно и нужно тестировать готовые решения. Нельзя просто так взять и выкатить непроверенное решение на общее интеграционное тестирование. Стенд может выделяться как под весь проект целиком, так и под конкретного разработчика (для тестирования экспериментальных веток). Эти стенды имеют более серьезные ресурсы, чем личные DEV-стенды разработчиков, но все еще ограничены рамками разумного, т.к. полное воссоздание всей инфраструктуры на ресурсах, выделенных проекту, было бы невероятно сложно, долго и экономически бессмысленно. Поэтому нормального интеграционного тестирования тут не получится, да оно и не нужно.
Несколько важных моментов, которые происходят на этом этапе:
Интересной особенностью этих командных DEV стендов является то, что его уже нужно готовить по всем правилам: устанавливать внутренний софт, создавать тестовых пользователей, и так далее. Обычно стенд — это не один компьютер, а кластер из виртуальных машин, поэтому в этот момент тестируется еще и правильная инициализация кластера. По сути здесь происходит еще и мини-инсталляционное тестирование всего стека, начинающееся прямо с момента развертывания стенда.
Конечно, в использовании Энсибла существуют свои заморочки. Например, стандартная система ролей может оказаться излишне простой для сложного модульного проекта. В самой свежей версии есть экспериментальная поддержка вложенных ролей, но и её может не хватить (тем более что она действительно очень сырая и не протестирована на совместимость с другими фичами Энсибла). Если пытаться использовать Энсибл полномасштабно, как систему не только конфигурирования, но и управления целевыми системами, придется написать много дополнительного обвязочного софта, где сам Энсибл является всего лишь “SSH-ассемблером” для более высокоуровневых команд.
Кроме того, быстро выясняется, что девопсы, плотно работающие с Энсиблом, должны знать Python. Например, у вас есть какой-то самописный софт, который обладает черезвычайно сложной процедурой конфигурации, связанной с тонкой настройкой кластера, линукса, прикладного ПО, и так далее. Многие из этих операций требуют работы с малоизвестными и нативными функциями, для которых сообщество не написало готовых решений, да и не напишет никогда. Если описывать это в плейбуке на “чистом ямле”, это заняло бы десятки страниц текста. А лог этих операций был бы трудночитаемой кашей — в, частности это связано с отсутствием нормального управления ветвлением и соответствующей выдачи лога (время от времени вопрос поднимается в сообществе, но воз и ныне там). Более правильный способ решения этой задачи — написание Action Plugin и Module, весь сложный код в котором инкапсулирован в изящно написанный скрипт на Python. По сути, в самом плейбуке остаются только вызовы плагинов, содержащие высокоуровневые бизнес-параметры — по аналогии с утилитами командной строки GNU/Linux. Из этого напрямую следует, что инженер-инфраструктурщик (девопс, админ, разработчик — кто угодно, кто занимается этой задачей) обязан знать Python на достойном уровне. Не обязательно знать его так же хорошо, как специальный Python-программист, но уметь читать и багфиксить готовый код, и писать простые модули для Энсибла — это рецепт успеха.
Полученный результат зачастую, по сути, является не просто каким-то “скриптом”, а весьма сложным софтом, требующим специальной поддержки. Именно отсюда пошло изначальное разделение на пару репозиториев: один для кода продукта, другой для кода скриптов развертывания. Для репозитория скриптов развертывания можно вообще использовать какую-то другую, специальную систему управления репозиториями (например, не Atlassian Stash, а GitLab со специфичными настройками), чтобы добавить больше гибкости в управлении конфигурациями.
Кроме описанных выше инструментов, существует еще множество мелких. Например, некоторые проекты все еще используют не GridGain, а SQL базы — там можно подключить Liquibase для накатывания миграций. И так далее. Такие вещи уже очень зависят от специфики проекта, и, по возможности, их стоит стандартизировать. Например, если мы выбрали Selenium в качестве фреймворка для UI тестирования, именно его и стоит придерживаться, т.к. поддержка таких решений требует большой экспертизы.
На следующем этапе происходит чистое, правильное системное тестирование на выделенном стенде.
Здесь происходит две ключевых вещи:
Установка и настройка среды зачастую сама по себе выявляет множество удивительных вещей, которые сразу же отправляются на доработку. В основном, они касаются простоты и удобства администрирования. Системы имеют тенденцию со временем разрастаться, сложность настройки увеличивается, и рубить эти проблемы нужно на корню — прямо начиная с этого стенда.
Набор автотестов “чистого” СТ тестирования может отличаться от “грязного” DEV-тестирования в сторону увеличения строгости. Даже самый незначительный экспериментальный проект обязательно должен иметь тесты, хотя бы базовое smoke-тестирование. Если тестов нет, на интеграционное тестирование этот проект не пустят.
Интеграционное тестирование — самое большое, сложное и важное тестирование. По крайне мере, таким оно кажется разработчикам, потому что на этом этапе находится самое большое количество сложных багов 🙂 Провести его нужно максимально аккуратно, потому что любая ошибка затрагивает результаты работы не только конкретного проекта, а еще сотен, если не тысяч людей.
На этом этапе стенды моделируют реальную инфраструктуру, имеют полноценные (весьма большие) ресурсы, и получают полную поддержку системных администраторов.
Происходит несколько обязательных вещей:
Полностью протестированный готовый продукт выкладывается в специальное централизованное хранилище дистрибутивов. Вместе с ним прикладывается вся доступная документация и другие материалы. Полученные файлы замораживаются навсегда. Используются специальные средства для того, чтобы поменять их было невозможно никаким образом.
(Если вы вдруг захотите сами сделать такое хранилище, и пишите на Java, можно просто использовать Nexus).
Проведение приемо-сдаточных испытаний — это другая тема, опасно приближающаяся к тайным знаниям. Но на верхнем уровне тут все просто, происходит:
После прохождения этого этапа можно считать, что продукт готов к эксплуатации.
Ну и наконец, развертывание в настоящей промышленной эксплуатации, написать про которое, по очевидным причинам, нельзя. Да и не имеет смысла, т.к. описанный выше пайплайн дотянется до прома только в конце года. В данный момент при развертывании на пром используется процедура ручной установки, с использованием инструкций по установке, приложенных к дистрибутиву, которая выполняется специальными экспертами по развертыванию.
В случае автоматизированного развертывания, на этом этапе будет две вещи:
ВСЁ. Этого минимального набора инструментов уже достаточно, чтобы куча людей могла ужиться под одной крышей. Важно понимать, что этот инструментальный стандарт не ограничивает возможности разработчиков, а дает стабильную платформу для дальнейшего развития.
Технологическое Ядро ППРБ
Читатель, знакомый с докладами Сбербанк-Технологий на конференциях JUG.ru (кстати, следующая будет совсем скоро), может заметить, что история девопса вышеописанной схемой не заканчивается. Скорее, она ей только начинается.
Статья начиналась с общего инструментального стека именно потому, что данные решения очень специфичны для самих Сбербанк-Технологий, и знать о них, скажем так, нужно не всем. Для тех кто все еще с нами — продолжаем.
Инновационные решения, применяемые в Сбертехе, требуют особенных подходов к разработке. В качестве причин можно было бы назвать разношерстный технологический стек, потребность в аггрегации данных от множества подсистем, невероятное количество серверов, необходимых для обслуживания такого объема данных, отсутствие “выходных” и “ночи”, когда можно провести обслуживание, и так далее. Несмотря на необходимость организовать высокую производительность, отказоустойчивость, и обслуживаемость 24х7, полученные решения должны работать на стандартном железе и не требовать специальных суперкомпьютеров. Результирующее решение должно одновременно обладать признаками и централизованной, и децентрализованной системы. Сложная ситуация.
В результате было создано так называемое Единое Информационное Пространство. Это кластерная архитектура, в которой все узлы объединены между собой, каждый может общаться с каждым. Нет никакого дублирования и интеграции, все данные существуют в одном экземпляре и доступны всем модулям с любого узла в любое время. В качестве бэкенда этой системы используется in-memory data grid под названием GridGain. На сегодняшний день, это одна из лучших в мире систем хранения и обработки больших объемов бизнес-данных.
Именно с этой архитектурой администраторам и девопсам приходится сталкиваться при проведении любого интеграционного тестирования. Именно она работает на обслуживаемых ими стендах.
Совершенно очевидно, что управление такой системой ортогонально движению артефактов вдоль CI/CD пайплайна. Jenkins и Ansible можно использовать для инициации инфраструктурных операций, но на них нельзя записать сами операции. Это просто другой логический уровень.
Для большинства компонентов на этой картинке, имеется как некая “серверная” составляющая (запускаемая на серверах-координаторах), так и прикладные библиотеки, которые обычный прикладной софт использует для работы внутри кластера. По сути, Технологическое Ядро дает свое видение на большинство привычных для любого программиста или админа вещей: как хранить настройки приложений, как хранить данные, как организовывать взаимодействие между программами, и так далее. В каком-то смысле можно думать о нем как о легкой кластерной операционной системе, работающей на основе Java.
Чтобы развеять налет магии, на низком уровне все это работает на основе всем известных и понятных вещей, выложенных в OpenSource.
GridGain можно посмотреть на примере бесплатного Apache Ignite (в чем между ними разница? Недавно, в интервью JUG.ru, об этом рассказывал Владимир Озеров). Apache Kafka, ZeroMQ, даже Hyperic — все это находится в Open Source. Они выбраны не только потому, что писать самостоятельную замену — долго и дорого (СБТ, вероятно, справился бы), но и затем, что для всех этих инструментов уже есть сообщество и понимание, как их обслуживание правильно делать в смысле выстраивания процессов администрирования и девопса. Например, если вы вдруг являетесь экспертом по Apache Kafka или OpenStack — быстрей идите в СБТ, вы здесь нужны.
Но также надо понимать, что работа с этими инструментами — это не администрирование, а именно девопс. Необходимо колоссальное количество разработки, чтобы превратить эти компоненты в однородную платформу. Транспорт — это не просто Kafka, это специальная кластерная среда, которая использует Кафку как бэкенд. Уровень хранения — это не просто Ignite/GridGain, а специальный софт, использующий передовые ноу-хау СБТ, касающиеся работы с IMDG, на который ушло очень много сил лучших разработчиков. Всем этим компонентам нужно со стороны обслуживания дать однородный интерфейс управления и просмотра диагностики (для администраторов), и однородные Java-интерфейсы (для программистов). Использование этих инструментов требует понимания и культуры использования ото всех участников процесса — и от администраторов, и от программистов, и от специальных инженеров по автоматизации инфраструктуры, и так далее.
Как видим, наличие стандартизированного CI/CD пайплайна не ограничивает полет инженерной мысли, а дает ему площадку для беспроблемного результативного развития.
Заключение
В этой статье мы рассмотрели как инструментальный стандарт CI/CD Сбербанк-Технологий (который может адаптировать каждый), так и специфические для Сбербанк-Технологий решения (которые напротив, могут использовать далеко не все).
Надеемся, что статья оказалась полезной: тем, кто хочет построить что-то подобное у себя; тем, кому просто любопытно; тем, кто хочет пойти на работу в Сбербанк-Технологии и сомневается — будет ли ему там достаточно интересно и приятно работаться. Если у вас еще нет девопса, можно использовать этот текст как руководство, или показывать друзьям: глядите, вот так у нас все будет хорошо к концу года.
Если хочется узнать больше о девопсе, приходите на нашу конференцию DevOops 2017, которая состоится в Санкт-Петербурге 20 октября 2017. Кстати, Сбербанк-Технологии — золотой спонсор этой конференции.
Благодарности
В подготовке этого текста помогали сотрудники Новосибирского отделения Сбербанк-Технологий: Александр Перковский (заместитель директора центра компетенции ППРБ), Алексей Курагин и Егор Федоров (архитекторы Технологического Ядра и разработчики системы мониторинга), Олег Чирухин (архитектор и разработчик системы развертывания ППРБ.BPM), Александр Обливальный (инженер по автоматизации инфраструктуры ППРБ) и другие. Мы не можем перечислить здесь всех, но признаем, что ваш вклад был неоценим. Спасибо!