BSIDESKyiv 2018 - Dmytro Shapovalov DELIVERING SECURITY PRODUCTS WITHOUT SHOOTING IN A FOOT

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

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

юзабилити это очень важный вопрос который я думаю что будет вдоль моего так совсем водах доклада я буду о нем говорить о буду на этот важный фактор ссылаться значит в чем же собственно особенность имплементации мы будем говорить так по большому счету стандартного стыка технологий которые используют большинство продуктовых кампаний по отношению к нашим продуктам которые выпуском the security продуктом ну конечно же первое что приходит но это отличная цель для атакующих мы разработаем open source продукты естественно замечательная смесь security продукты открытый исходный код ну в общем то замечательно давайте будем пробовать ломать может что-нибудь получится вообще тема open source и security продуктов вот в одном security продуктов поставляемых и разрабатываемых open source вообще очень отдельная интересная тема который совершенно идет спор по поводу

того имеет лиц и то есть цель целесообразно лет по наш взгляд получите дополнительный расскажем вам о и голлинг мамашку смотрит многие дополнительные десятки сотни тысячи глаз наша аудитория

наша целевая аудитория это квалифицированный и очень при путине инженер поэтому опять же в этом случае

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

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

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

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

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

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

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

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

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

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

нашем open source и и по истории и конечно же множество платформ как linux платформы так и мобильные приложения с которыми тоже и мы прошу прощение мобильные платформы с которыми работают наше приложение что является критичным для нас и какое наше видение вообще по коду пусть бы по проблеме о которой мы сегодня говорим но в первую очередь практически визе мы попытаемся использовать автоматизацию ну что автоматизации на наш взгляд это в первую очередь возможности избежать ошибок это возможность экономить время специалистов это возможность существенно повысить продуктивность выборе технологий и программных компонентов мы всегда руководствуемся идей простоты и ясности и понятно понятно значит можно конечно [музыка] можно выбрать множество замечательных компонентов которые есть сегодня на рынке не думая о простоте в архитектуре

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

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

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

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

сформулировал и дав ответ на этот вопрос мы дальше перейдем уже к инженерным вопросом к выборам технологий к выборам решений к топологии всему остальному 1 инженерный вопрос естественно в структуре каким образом наш продукт будет то есть какой будет выглядеть из каких компонентов он будет состоять

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

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

технологии мы будем при этом использовать такие каналы связи будет этой цели либо как в некоторых наших продуктах обертка секиру саша который мы сделали для упрощения процесса внедрения наших компонентов и для того чтобы уйти от проблем с безопасностью vs el которые на дне сегодняшний не решены каким образом мы будем масштабировать наш продукт это очень важный вопрос на день сегодняшний мы прекрасно знаем что даже маленький стартап на день сегодняшний может вырасти за очень короткий период времени в достаточно большой крупный проект поэтому на это на этапе планирования архитектуры вы безусловно должны задать себе этот вопрос далее какие внешние зависимости вы планируете использовать мы стараемся ограничиваться использованием минимума внешних зависимостей ну в частности основа нашей библиотеке липкими с она использует в

качестве внешних зависимостей только у панаса цели бабурин с.н. использование внешних зависимости часто может привязать вас либо к определенному капри к определенной библиотеки либо к определенной платформе либо в дальнейшем вызвать проблемы с совместимостью если вы допустим к примеру разрабатывать разрабатывать изначально приложение на unix системах потом вы хотите вынести его либо на mac os либо еще так сказать куда нибудь если вы привязали достаточно большому количеству библиотек то у вас сразу скорее всего будут какие то вопросы совместимости забегая чуть-чуть на период мы испытывали проблемы интеграции мобильных приложений на mac os с linux системами несмотря на то что и там и там в общем то использовали схожий библиотеки и стек библиотек использования у нас минимален когда вы когда вы выбираете библиотеку вы всегда

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

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

разработку тестирования написание библиотек создания документации обучение поддержания развития пользователя вас будут требовать объяснений а зачем вы использовали этот ваш новый стандарт чем он лучше вместо того чтобы использовать но существующие естественно вас дальнейшем возникнуть вопросы интеграции как вы планируем доставлять наши продукты помни о нашей конечной цели что мы должны сделать такой продукт который в конце концов будет из пользоваться на этапе проектирования мы должны понимать каким образом и в каком виде будут эксплуатироваться наши продукты на этом этапе хотелось бы конечно получить максимально возможный охват потенциальной аудитории поэтому стоит об этом позаботиться в самом начале классическая схема распространения open source продуктов естественно является исходный код как работать с исходным кодом знают наверное большинство разработчиков даже так стать средненько лет даже средне

квалифицированные пользователи умеют собрать простейшие приложение поэтому вариант стандартный безотказный у нас исходный код естесно расположенных репозиторий то стандартно 11 сегодняшнее решение о том кто использует такой подход при наличии альтернативных вариантов на день сегодняшний конечно же первую очередь такой подход используют люди которые интегрируют наши продукты в своим люди которые готовят наши продукты для серьезного production а потому что ну часто бытует мнение что безопаснее собрать рабочий экземпляр из открытого исходного кода для того чтобы быть уверенным что мы не имея никаких закладок никаких так стать дополнительных проблем с уязвимостью второй второй способ распространения конечно же это менеджера пакетов это red катарские стандарт это стандарты bean порта chess free выезде и мерч brew много их здесь имеет смысл готовить ваши

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

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

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

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

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

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

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

момента когда все стали всей системы про ниц и ализе раваны получить уже готовы какой-то вывод о состоянии приложения о том как она разворачивается как она запускается мы приняли несколько стандартов вывода которые используются во всех наших приложениях это вывод файла это стр это syslog в общем-то вполне стандартные вещи которые через который мы можем получить интеграцию практически с любыми приложениями для сборки логов метрики основная задача метрик это информация о доступности приложения о состоянии здоровья отдельных его компонентов и конечно производительности сбор дополнительной статистике произвольной в качестве вывода мы используем стандарт prometheus prometheus мы очень любим но кроме всего прочего чем хорош стандарт prometheus он прост он функционален он хорошо описан если вам необходимо интегрировать любой другой системой мониторинга пожалуйста это делается

одним скриптом my общем-то портится очень легко как часто вы задумываетесь при разработке приложения от рейсов особенно многокомпонентного приложения я об этом честно говоря редко слышу когда на самом начальном этапе кто-то говорит о трейси залогов до о метриках возможно от рейсах редко зачем нужен третьем когда вы анализируете многокомпонентную вашу ваше приложение многокомпонентные часто вам хочется его настроить соответствующим образом получить данные о производительности получить данные о том как ваш запрос обрабатывается на каждом из этапов каждым из компонентов и здесь обычная стандартная схема не мониторинга ни воды ни l'one логирования не позволят вам сделать это почему потому что особенностями трейдинга является идентификацией одного и того же запроса и трассирования его вот по всей цепочке между вашими компонентами и сбора

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

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

полной автоматизации по каким причинам я уже сказал дальше стандарты внутренние по разработке приложения мы говорили ранее о стандартах которые мы используем для ваших технологий которые используются в ваших приложениях теперь стал теперь кратко скажу о стандартах разработки зачем они нужны для синхронизации всех членов вашей команды это по сути внутренние api между ними это по сути позволяет им коротко и ясно общаться это позволяет унифицировать подходы это позволяет сделать ваши продукты гармоничными и стыкующихся друг с другом основная идея правил это упростить внутренний процесс то есть ни в коем случае правила не должны быть сложены ни в коем случае не должны достаточно сильно ограничивать разработчика какие мы приняли для себя правила у нас были проблемы с versio нирования 11 наш продукт имел два числа

версиях второй наш продукт имел три числа версиях третий продукт у нас имел дополнительные какие-то поля в результате все это при стыковке между собой при прописывание зависимостей возникали сложности когда мы говорим об автоматизации когда мы говорим о каких-то универсальных подходах то естественно здесь необходимо принять стандарт стандарт мы приняли самый простой три числа надеюсь сегодняшних классика жанра этот стандарт позволяет нам с одной стороны информировать пользователей о том где мы делаем их где и когда мы делаем изменение пользователя наши знаю что это кстати если меняется минорная цифра понятно что это мелкие изменения to fix и если меняется где прощение за меняется так соединил две версии это мелкие изменения и минорной то уже возможны какие-то брыкин через дальше именование принятые стандарты в

именовании ранее был была разница достаточно серьезная что опять же вызывало проблемы с автоматизацией проблемы с удобством для пользования пользователь ожидал одного и того же стандарта именования получал различные важно этот стандарт не только принять мы и в дальнейшем поддерживать поскольку так стать очень многие пользователи под ваше приложение в конце концов напишет интеграционные скрипты и каждое изменение естественно будет вызывать необходимость эти скрипты корректировать одна из важнейших вещей которые мы приняли у себя это стандарты именования веток в git репозиторий по сути это стандартный guide full но мы его чуть-чуть описали для себя и самое главное сделали его понятным мы сделали понятным действие которое происходит при каждом изменении в этом репозитории кроме стандартной мастер ветки в котором находится текущее состояние работающие

состоянии мы выделили 100 еблу ветку которой находится за видом заведомо стабильные релизы и выдели естественно ветки для разработчиков по каждой по каждому из типов веток мы описали действия которые автоматически будут происходить по веткам stay было мастер у нас автоматически запускается целый цикл тестирования целый цикл сборки пакетов интеграции delivery соответственно чем раньше вы внедрите ваши внутренние стандарты тем вам будет проще и дешевле все это разрабатывать кратко об инфраструктуре основные части с точки зрения нашей сегодняшней проблемы это естественно ядро инфраструктура для разработки инфраструктура себя сидим теперь подробнее о сидим вот здесь в общем то начинается достаточно интересная вещь которую нам удалось реализовать вы видите перед собой croteam q схему о которой я говорил то есть по различным

изменениям в каждой из веток выполняются цикла тестов самое главное что вы можете здесь увидеть это две системы тестирования стекол seo и и billboard почему 2 и почему именно такие здесь чуть подробнее song версия и это замечательная система тестирования которую часто используют разработчики для проверки для быстрой проверки того что они написали то есть это простейший юнит-тесты это простейшая проверка функционала по нашему опыту этой проверки крайне недостаточно поэтому а вторая часть и боль и гораздо более обширная часть всех тестов у нас производится на нашей собственной платформе к на которой запущен был год но билл будут существенно доработан и здесь мне придется чуть-чуть сказать о почему именно billboard очень неплохой chromium франьо который нам позволяет написать любой функционал

сделать его гибким и позволяет выстроить внутреннюю структуру тестирования ту которую нам надо поэтому сделал такой выбор варианты с дженкинсом и прочими вещами мы тоже рассматривали но мы их отбросили по той причине что тот же самый jenkees автоматически развернуть есть очень большая проблема все таки есть операции которые там все равно выполняются руками а мы предпочитаем полную автоматизацию как я уже сказал на съемках мы выполняем стандартные юнит-тесты набил боте что мы выполняем набил бы этим мы выполняем unit-тест она уже unit тесты на всех платформах для которых мы выпускаем продукты мы выполняем кросс-платформенной тесты это очень важно с добавлением кроссплатформенных тестов мы нашли один баг который в общем-то ранее был неизвестен у нас было несовместимость между двумя платформами у нас была не совместилось

между в архитектурами ввиду особенностей библиотек между платформами x 6 x 864 и 308 что у нас было несовместимость поэтому кросс повторные тесты обязательно интеграционные тесты этот тест и со всеми компонентами которые с которые могут взаимодействовать наши продукты со всеми вариантами баз данных это web компоненты которые у нас есть в составе нашего приложения проверки предрелизной проверки очень коротенькие простенькие тесты которые тем не менее облегчает нам жизнью в день релиза это проверки о том что мы все необходимые изменения которые должны были не вынести в код мы внесли это номера версии это изменение в документации и так далее так далее набил быть и же происходит подготовка пакетов и тепло их в наш репозитории как мы построили наш был год мы взяли

ядро которое позволяет делать достаточно гибкие вещи мы написали свой движок для build бота и мы сделали третью часть сценарий почему именно так в принципе у нас как я уже сказал все инженеры и все знакомы с понтоном и каждый мог бы на python не написать то же самое сценарий для любого из приложения но на наш взгляд сценарий надо писать быстро сценарии должны быть простыми понятными и читабельны me когда мы пишем их на python всегда есть некий избыток куда который нам надо читать для того чтобы увидеть всю картину вот так вот примерно выглядит сценарий ямал сценарий который мы используем для конфигурации нашего billboard для чего это ещё было сделано того чтобы в дальнейшем наши наши разработчики сами могли писать эти

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

какая была причина причина была в том что набил будьте пожгли в режиме ссср был с configure сконфигурирован строго и не принимал каких-либо так стать и не принимал не не зашифрованных соединений на мкс гре работал в стандартном режиме он принимал secu session соединений соединения и при необходимости он делал переход на естественный шпиона и соединение ввиду этого тесты пытались подключиться псы у них это сделать не получалось они благополучно переключаясь на низшем водный режим и тесты проходили фактически не работал мы стараемся писать сценарии согласно документации которая согласно официальной документации все сценарий которые у нас написаны по проверке инсталляции по проверке интеграл по проверке интеграционных сшибал у нас написано в строгом соответствии с документацией они полностью соответствуют всем шагам

опять же это нам позволяет быть уверенным в том что документация наша верна

одно из основных правил примите четкую методику тестирования и следуйте ей не пытайтесь ее изменить в процессе вашего короткого спринта или не с принтами отрезка времени который вы разрабатываете если вы это будете делать вы будете идти вслед за проблемами а не пытаться их решить катенька как происходит процесс автоматический процесс сборки по информации от give up происходит проверка кода в дальнейшем при лист с ты unit тесты тесты кроссплатформенные интеграционные тесты дальше сборка пакетов после сборки пакетов и доплыл их в нашей базе торе и мы наши же пакеты тестируем на установку далее сборка и матчей для докера и собственно тесты doki doki как я говорил мы его любим и использую недавно у нас были существенные изменения в образах докер что было

раньше раньше образы докер файлов для всех наших компонентов занимали мегабайт по 900 надеюсь сегодняшний к сожалению то такая распространилась член тенденция когда мы берем какой-нибудь дистрибутив в качестве основы докер файла на основе его пишем пишем весь сценарий и получаем на выходе вполне готовый работающий дистрибутив на размеры мы не смотрим размеры получаются сумасшедшие даже когда мы пытаемся сжать их мы все равно получим достаточно больше 600 мегабайт 700 мегабайт о том как мы уменьшали размер наших контейнер у нас есть замечательная статья в нашем сайте ссылка будет позже большинство разработчиков к сожалению об этом не думает и наверное половина а может быть даже больше образов докер имеют достаточно большой размер мы думаем о том мы считаем миллисекунды когда мы разрабатываем наши сайты мы

считаем миллисекунды когда соревнуемся за место в позиции google но мы не думал о том что наши контейнеры по 900 мегабайт требует значительного времени на разворачивание но нам удалось уменьшить размер каждого из наших контейнеров ну там примерно 60 раз 950 до 15 мегабайт техники которые мы применили но замечательная техника которая есть в докере с версии 17 5 это прошлый год мы молча стоишь builds и сборка счас крича которые в общем то было и ранее здесь есть маленькая ноу хау а просто так скомпилировать техническую библиотеку у нас ввиду того что мы используем внешность и шиной зависимости у нас не получается поэтому нам пришлось написать собственный скрипт который автоматически собирает все необходимые библиотеки в прибьют контейнеры после этого формирует

готовый image ну как вы видите так стать вот размеры получившийся образов от 8 до 16 мегабайт прошу вас заботиться о ваших пользователях добавили мы тэги добавили мы метки к нашим контейнером еще одна важная вещь и которое хочу сказать это докер кампус чтобы как мы используем докер кампус мы постарались кроме стандартного его использования в виде сценария для разворачивания какого-то стента мы постарались его использовать и как средство для демонстрации средство для первого ознакомления с нашим продуктом поэтому на день сегодняшний наш и докер кампус файлы выглядят примерно таким образом они сама документированные они в них много мы подготовили каждый отдельный кампус файл на каждый демонстрационный стенд самое главное не сейчас развращена с одним единственным действием и не требуют предварительной

подготовки по ключам по раскладыванию ключей которая была достаточно сложной процедурой в предыдущих вариациях мы в наших докер кампус файлах детально описали конфигурации детально описали топологию это позволяет визуализировать то каким образом наши компоненты стыкуется это позволяет визуализировать границы которые границы которые мы должны построить с точки зрения безопасности и так наверное к выводам разработка и дали very secure key продуктов как видит достаточно то кстати ответственно и серьезно и задание поэтому мы очень постарались сделать множество улучшений которые произошли за последние полгода для того чтобы сделать продукт в конце концов гораздо дружелюбнее гораздо ближе к пользователю мы внедрили внутренние стандарты мы сделали наши продукты скажем так таковыми которые были понятны нашим пользователям пользователь понимают чего-то ждать пользователь понимает когда мы будем

делать брыкин сейчас пользователи понимают когда мы делаем маленькие фиксы пользователи понимают все что у нас происходит собственно

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