Русский
Русский
English
Статистика
Реклама

Sdlc

Процессы разработки, или сколько стоит сделать сайт

05.10.2020 16:20:50 | Автор: admin

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

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

В прошлом месяце я общался со стартапом. У него есть работающий веб-сервис, который разные люди писали несколько лет, и теперь руководство думает что с ним делать. Основатели рассказали мне о своем желании нанять команду из десятка разработчиков, чтобы переписать или модернизировать приложение. Я спросил их про user story, документацию, трекер задач, и они ответили, что этого у них нет. Они попросили составить список того, что я предлагаю им сделать, и я написал вот это:

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

  2. Определить контексты по DDD и создать высокоуровневую документацию, чтобы обсуждать архитектуру и помочь новым разработчикам осваиваться в проекте.

  3. Определить узкие места системы, которые вызывают проблемы с масштабированием и доступностью.

  4. Согласовать среднесрочные цели IT-команды с высшим руководством.

  5. Создать рабочий процесс на инструментах командного взаимодействия - таких, как доска, трекер, мессенджер, репозиторий.

  6. Организовать процесс найма и вхождения в проект новых разработчиков.

  7. Наладить системы мониторинга и бекапа.

  8. Сделать декомпозицию среднесрочных задач по этапам и написать календарный план.

  9. Сделать CI/CD.

  10. Написать план изменения архитектуры.

  11. Выставлять приоритеты задачам в беклоге.

  12. Наладить регулярные встречи IT-команды с продактом и отчеты высшему руководству.

А где разработка? Ответ - весь список. Все это входит в Жизненный цикл ПО".

Владельцы стартапа сказали, что им не нужен менеджмент, им нужна операционная деятельность. Спасибо добрым людям за отзыв. Он навел меня на мысль написать заметку и подробнее рассказать, что такое разработка, и почему перечисленное по большей части не относится к управлению.

Все перечисленное связано с деньгами.

  1. Ключевые параметры, которые влияют на продажи: трафик, конверсия, возвраты, сколько клиентов возвращается, сколько уходит, и так далее. Мы все любим исследования, обсуждать культуру разработки, спорим из-за стандартов, но оценка IT-компаний - это произведение годовой выручки или размера клиентской базы на мультипликатор, и код не принимается во внимание вообще. Задачи разработки должны быть привязаны к важным измеримым параметрам бизнеса. Я принимал участие в разработке множества проектов, и помню несколько случаев, когда владельцы-управляющие растущих проектов игнорировали серьезные изменения ключевых параметров. Один проект терял трафик из-за конкурентов, у другого выросли возвраты денег за оплаченные покупки. Игнорирование этих проблем разрушило проекты всего за несколько месяцев после многих лет работы. Несмотря на то, что технически эти проекты надежны, и до сих пор приносят небольшие деньги, доля рынка потеряна навсегда. Обратную ситуацию я помню в корпорации Oracle. Каждому сотруднику: разработчику, тестировщику, менеджеру рассказывали о том, сколько миллионов долларов выручки у продукта, над которым они работают, какая рыночная доля, сколько клиентов пришло, сколько осталось, кто конкуренты, и так далее. Были общие собрания, на которые приезжали вице-президенты, и делали для коллектива тот же доклад по результатам, который они делали перед советом директоров. Как можно видеть по отчетам Oracle corp, такая концентрация на результатах работает очень хорошо.

  2. Бизнес-логика - хороший критерий разделения системы на модули и сервисы. Определение контекстов помогает людям понимать друг друга, уменьшить потери времени в общении и определить зоны ответственности. Кроме того, изучение логики приложения - часть процесса найма новых сотрудников. Инвестиции в высокоуровневую документацию окупаются с каждым новым сотрудником, модулем системы и сервисом.

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

  4. Среднесрочные цели - это то, за что компания платит сотрудникам IT-подразделения. Писать планы - не критично для выживания компании, но их отсутствие обычно означает, что разработчики только играют в исследования и спорят о стандартах, но мало времени уделяют тем задачам, которые могут повлиять на бизнес.

  5. Процесс разработки с доской, трекером задач, системами контроля версий, совещаниями, проектированием, code review, сборкой, тестированием и выкладкой - естественный для большинства команд. Мы просто не можем предсказуемо и постоянно выкладывать в работу задачи и соблюдать SLA - процент времени доступности системы, без надежных процессов разработки.

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

  7. Мониторинг систем, протоколирование, планы резервного копирования и восстановления - не первоочередные задачи, которые нужно выполнять при запуске MVP. Это становится выгодно, когда проект начинает тратить деньги на привлечение клиентов. Все однажды ломается, и чем больше бюджет, тем важнее становится способность системы обслуживать поток денег непрерывно. Резервные копии данных - это не управленческое решение, это естественный способ сократить простои.

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

  9. Выгода от непрерывной разработки и непрерывной доставки (CI/CD) не очевидна. По закону Лемана, сложность программного обеспечения растет вместе с развитием системы, если не принимаются меры по сдерживанию роста сложности. CI/CD - это усилия команды разработчиков по сдерживанию роста сложности. Покрывая код тестами и запуская их на стендовых серверах при сборках, мы сдерживаем рост затрат на разработку. Эта задача находится внизу списка потому что она оправдана только для растущих и успешных проектов. Для большинства обычных проектов достаточно выкладки из релизной ветки git. Если растем без CI/CD - тоже ничего страшного, однако, нужна команда QA такого же размера, как команда разработчиков, удваивается площадь офисов, количество техники и менеджеров на совещаниях. Проект будет медленнее расти, но на растущем рынке можно не замечать этого годами. Я знаю несколько крупных проектов без тестов, в каждом тратят сотни тысяч долларов в год на переписывание тех частей кода, которые не были покрыты тестами.

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

  11. Выставлять приоритеты задачам в беклоге можно по-разному, нет единого правила для всех. В методологии SCRUM приоритеты выставляет команда на planning-совещаниях. В традиционных моделях приоритеты выставляет руководитель команды. У руководителя-чайки нерегулярность изменения приоритетов приводит к отсутствию приоритетов вообще. Людям удобнее работать, когда они знают правила определения приоритета задач. Когда правила известны, люди учатся выполнять более важные задачи, чтобы чувствовать себя важными.

  12. Регулярные встречи с руководством, отчеты лицам, которые принимают решения, и внимание позволяют людям чувствовать, что они правильно поступают, ощущать себя частью чего-то большего. Это помогает команде пережить кризисы.

Итак, сколько времени займет сделать веб-сервис? Чаще всего, ответ будет "Возьмите Wordpress, как поступили 38% веб-сайтов в интернет. Зачастую задачу можно решить без команды программистов. Можно использовать SAAS, взять коробочное решение или отдать задачу на outsource. Конечно, если вы не строите бизнес в IT. По законам Лемана, чтобы не отставать от конкурентов, разработка ПО должна продолжаться в течение всей жизни продукта. Когда бизнес будет расти, появятся управленческие и операционные процессы, архитектурные задачи, бизнес-анализ, юридические, бухгалтерские, финансовые процессы, связи с общественностью, корпоративные правила.

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

Подробнее..

Вебинар Secure SDLC безопасность как фундаментальный аспект разработки

20.07.2020 16:23:27 | Автор: admin


28 июля в 11:00 (МСК) приглашаем на вебинар Digital Security, где рассмотрим процесс Secure SDLC со всех сторон.

Зарегистрироваться без лишних слов

Разработчики ПО, прямо или косвенно, влияют практически на все сферы экономики и порой кардинально меняют представление пользователя о привычном.

Круто быть разработчиком, но и ответственно: хорошая репутация в сообществе и на рынке зависит от ряда факторов. Один из важнейших безопасность выпускаемого ПО. Поэтому всё больше компаний внедряют процесс безопасной разработки и обеспечивают защищённость продукта ещё на этапе написания кода. Об этом и поговорим 28 июля с экспертами Digital Security.

В программе вебинара:

  • Какие бизнес-задачи решает Secure SDLC
  • Как строится Secure SDLC: схема проверки, инструментарий, согласование графика релизов
  • Вот такие баги ловит команда Secure SDLC: кейсы из практики Digital Security
  • Жизнь после SDLC: дальнейшее развитие APP Sec в компании

Для кого:

  • Руководители компаний-разработчиков ПО
  • Руководители отделов разработки
  • Руководители и сотрудники подразделений ИБ компаний-разработчиков

Ну, вот теперь точно зарегистрироваться

Ждём вас и ваши вопросы на вебинаре 28 июля в 11:00 (МСК).
Подробнее..

Оценочный уровень доверия (ОУД4) и ГОСТ Р ИСОМЭК 15408-3-2013. Введение

18.02.2021 10:20:32 | Автор: admin

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


В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. Secure SDLC или Secure software development life cycle). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.

Этой статьёй я хочу начать цикл, освещающий процессы безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. Моя задача последовательно, фундаментально и лаконично изложить этот фреймворк, чтобы уменьшить порог вхождения в предмет. Материал предназначен для разработчиков, менеджеров, методологов и других людей, которые в силу обстоятельств, вынуждены погружаться в безопасную разработку в контексте ОУД и требований Банка России. В подготовке материала мне помогал независимый эксперт и специалист по информационной безопасности - Рустам Гусейнов.


Подробнее под катом

Оглавление

  1. Введение и цели цикла

  2. История и эволюция фреймворка

  3. Центральный банк как популяризатор ОУД4

  4. Общие положения и концепции ОУД4

  5. Заключение

  6. Полезные ссылки и материалы

  7. Приложение (список сокращений)

Введение и цели цикла

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

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

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

История и эволюция фреймворка

ОУД расшифровывается как оценочный уровень доверия. Из самого названия следует цель фреймворка гарантировать соответствие продукта определенным критериям, заявленным в соответствующих стандартах, чтобы пользователи (заказчики, владельцы, физические лица и т.д.) могли доверять программному или аппаратному обеспечению, прошедшему необходимые проверки и декларирующему через них соответствие необходимым требованиям. Чтобы не уходить в длинную лекцию о разработке, уязвимостях, их эксплуатации и сопутствующих рисках, напомним, что любая ИТ-система теоретически (а на деле чаще всего и практически были бы ресурсы!) несовершенна. Поэтому в силу различных недостатков, связанных с:

- архитектурой (дизайном);

- разработкой (кодированием архитектуры в конечный продукт);

- внедрением (настройкой);

- эксплуатацией (обслуживанием).

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

Рисунок 1. Иллюстрация вектора атаки

Корни фреймворка уходят в становление индустрии ИБ в США в семидесятых и восьмидесятых годах прошлого века. По мере автоматизации и развития системного подхода силовые ведомства стремились гарантировать надежность системных компонентов, используемых государственными структурами для защиты информации. В течение какого-то времени несколько подобных стандартов существовали в различных юрисдикциях параллельно, пока не были объединены международными организациями ISO/IEC в новый, единый фреймворк ISO/IEC 15408 Common Criteria for Information Technology Security Evaluation (или просто Common Criteria то есть Общие Критерии). Любопытные до истории и фактов могут изучить подробности хроники по ссылкам внизу статьи, нас же интересует тот факт, что отечественные стандартизаторы с 2012 года начали анализировать и перерабатывать указанное семейство стандартов, чтобы издать их официально на русском под эгидой Стандартинформа.

Здесь стоит сделать небольшое отступление про статус подобных стандартов. На фоне вступления России в ВТО и либерализации законодательства национальные стандарты перестали быть обязательными на территории Российской Федерации. Сегодня, в соответствии со ст. 27Федерального закона 162-ФЗ О стандартизации, ГОСТы на территории России являются обязательными тогда, когда на них явно ссылаются какие-то нормативно-правовые акты уполномоченных органов государственной власти. Здесь на сцену выходит Центральный Банк России.

Рисунок 2. Титульный лист ГОСТ Р 15408-1-2012

Центральный банк как популяризатор ОУД4

Примерно в то время, когда Стандартинформ публикует первые документы семейства ГОСТ 15408, Банк России, в соответствии с международными трендами, начинает ужесточать требования к информационной безопасности платежей и кредитных организаций. Его целью является обеспечение устойчивости и надежности платежной и банковской системы, в том числе борьба с мошенничеством и несанкционированными переводами. Летом 2012 года принимается знаменитое положение 382-П, которое на следующие 8 лет становится основным нормативом по информационной безопасности для организаций, занимающихся денежными переводами на территории РФ (не считая более нишевых и специфичных требований, вроде стандарта PCI DSS, которые существовали и до этого).

С положения 382-П начинается внедрение ОУД 4 в жизнь финансовых организаций. В мае 2018 года Банк России, сталкиваясь с фактами печальной статистики уязвимостей ДБО и иных публично доступных интерфейсов взаимодействия с клиентами, вносит изменения в упомянутое Положение. Среди них содержится п. 2.5.5.1, цитата:

необходимо обеспечить: использование для осуществления переводов денежных средств прикладного программного обеспечения автоматизированных систем и приложений, сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, в соответствии с законодательством Российской Федерации или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 .

В последующие годы это требование, в уточненном и видоизмененном виде, появлялось в других нормативах ЦБ, и по состоянию на 2021 год прямо или косвенно вытекает из:

- 672-П (через ссылку на ГОСТ Р 57580.1-2017, где в требованиях ЖЦ.8 и ЖЦ.20 косвенно формулируется ежегодный ОУД4);

- 683-П;

- 684-П;

- 719-П.

Некоторые шероховатости формулировок и весьма общее указание на границы применимости ОУД в историческом 382-П, где было упомянуто прикладное ПО для осуществления перевода денежных средств, породили разночтения и длительные споры участников рынка об области применения ОУД. Стал популярным вопрос: надо ли проводить работы по ОУД в отношении всех информационных систем, участвующих в переводе денежных средств (например в отношении АБС), или все же речь идет о каких-то наиболее критичных/высокорискованных системах? Впоследствии эти вопросы были разрешены официальной позицией регулятора. Забегая вперед скажем, что требования к работам по ОУД касаются лишь того ПО, которое соответствует одному из двух условий (либо обоим):

  1. ПО распространяется клиентам организации (физическим или юридическим лицам);

  2. ПО доступно через интернет неограниченному кругу лиц (а не закрыто VPN или иными ограничителями).

Рисунок 3. Границы применимости ОУД для приложений финансовых организаций

Рассмотрим, для примера, как эта логика работает для банков. Из п. 4.1 Положения 683-П, которое устанавливает требования к ИБ кредитных организаций, вытекает необходимость работ по ОУД для ПО распространяемого кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также {ПО}, обрабатывающего информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием {} Интернет . В информационном письме Банка России от 8 июля 2020 г. N ИН-014-56/110, посвященном ОУД, приведена ссылка на Профиль Защиты Прикладного ПО, как на методику проведения анализа уязвимостей (подробнее об этом документе поговорим ниже). В свою очередь в п. 2.3.1 упомянутого Профиля развернуто сформулированы критерии подпадания прикладного ПО под работы в соответствии с ОУД4: клиентское ПО и/или выход в интернет. В упомянутой цитате из профиля находим:

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

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

- устанавливается в изолированном сегменте сети, сопряженном с сетью Интернет, на инфраструктуре финансовой организации, входит в состав автоматизированной системы финансовой организации и взаимодействует с обеспечивающими компонентами автоматизированных систем (фронт-офисное СПО);

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

Таким образом, спор о границах применимости ОУД был разрешен, а широкая формулировка границ применимости, проистекающая из 382-П уйдет в небытие вместе с указанным положением (оно утрачивает силу 01 января 2022 года на основании положения Банка России 719-П). Остается единственный вопрос как быть, если несколько приложений подпадают под требования? Наш ответ неоригинален риск-ориентированный подход и приоритизация проектов по ОУД внутри организации, особенно в условиях жестко лимитированного бюджета. Такую приоритизацию можно выстраивать на основании масштаба финансовых переводов, с учетом количества обрабатываемых персональных данных или исходить из других, менее очевидных соображений, например возможностей команды разработки оказывать поддержку проекту. В любом случае у вас наверняка есть более критичные каналы взаимодействия с клиентами и есть менее критичные. Если бюджет проекта ограничен, а количество различных приложений подпадающих под ОУД велико, самый простой критерий принятия решения - финансовый.

Теперь, когда мы изучили контекст вопроса, определились с границами применимости требований, решили в какой последовательности мы будем прогонять наши продукты через горнило ОУД, давайте поговорим о ключевых особенностях фреймворка и сделаем его обзор.

Общие положения и концепции ОУД4

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

Ключевыми документами, для понимания фреймворка, являются упомянутые в ссылках ГОСТы, которые не только вводят терминологию, но и содержат многочисленные разъяснения и примеры его различных аспектов. Ниже перечень, на наш взгляд, наиболее интересных и полезных:

  1. ГОСТ 15408-1-2012

  2. ГОСТ 15408-2-2013;

  3. ГОСТ 15408-3-2013;

  4. ГОСТ 18045-2013;

  5. ГОСТ 57628-2017;

  6. ГОСТ Р 58143-2018.

Общий процесс разработки и тестирования, согласно фреймворку, описывается в первой части ГОСТ 15408. В общем случае жизненный цикл продукта может быть представлен так, как показано на рисунке ниже.

Рис 4. Управление конфигурацией и жизненный цикл продукта (согласно ГОСТ Р 15408-1-2012)

Этапы работ, формирующих ОУД, описываются в третьей части стандарта ГОСТ 15408, как показано на следующем рисунке.

Рис 5. Компоненты, формирующие ОУД

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

  1. Ключевых концепций и ролей;

  2. Базовых процессов (взаимодействий) и их результатов.

На базовом уровне можно выделить три ключевые роли:

А. Заказчик (может совпадать с пользователем или владельцем), который использует некий продукт и требует соответствие этого продукта неким установленным требованиям к ИБ;

Б. Разработчик, который создает этот продукт и выстраивает его жизненный цикл, в соответствии с требованиями Заказчика;

В. Оценщик, который проверяет соответствие разработанного продукта установленным требованиям.

Здесь нужно сделать оговорку, что несмотря на методологическую рекомендацию разделять описанные выше роли между субъектами во избежании конфликта интересов (например, чтобы не проверять самих себя, а привлекать третью, независимую сторону), на практике, в некоторых случаях, такое совмещение ролей допустимо и легально. Например, в последнем абзаце п. 9 Положения 684-П сказано, что анализ уязвимостей по требованиям к ОУД4 может проводиться некредитными финансовыми организациями самостоятельно, без привлечения третьей стороны (для сравнения в текущей редакции 683-П такого пункта нет, и подобные работы необходимо осуществлять с привлечением сторонней организации лицензиата ФСТЭК).

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

Какие же процессы и взаимодействия возникают в ходе работ в соответствии с фреймворком ОУД? Практически каждый процесс ИБ начинается с описания границ проекта и требований, безопасная разработка не исключение.


В общих чертах фреймворк декларирует следующую последовательность действий:

  1. Разработать документацию и политики на продукт, которые регламентируют требования к ИБ приложения и разработки;

  2. Обеспечить практическое применение документов в разработке конкретного продукта;

  3. В ходе тестов, оценки соответствия и/или анализа уязвимостей подтвердить, что установленные на уровне документации и политик требования выполняются де-факто и позволяют достичь необходимого уровня безопасности (по сути защитить продукт от нарушителя ИБ с определенным потенциалом).

Ключевым элементом фреймворка является объект оценки (или ОО, например, ДБО, или какой-то компонент внутри ДБО), к которому предъявляются функциональные требования к безопасности (или ФТБ, например, необходимая реализация системы управления доступом или стойкая криптография), формулируемые в задании по безопасности или профиле защиты (разница между двумя в том, что задание по безопасности обычно создается Заказчиком самостоятельно, под себя; а профиль тиражируется различными институциями как минимально-адекватный стандарт для какого-то класса решений, например для межсетевых экранов или антивирусов). Так как объект оценки существует не в вакууме, а актуальные уязвимости связаны не только с разработкой и проектированием, но и с настройкой и эксплуатацией объекта, важными понятиями являются среда функционирования и конфигурация среды/объекта оценки. Наконец, сам оценочный уровень доверия представляет собой гамбургер из большего или меньшего набора компонент, в зависимости от выбранного уровня (смотри рисунок 5 выше).

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

Такое подтверждение может осуществляться с помощью двух базовых сценариев:

  1. С помощью сертификации (делается специализированными лабораториями, включенными в систему ФСТЭК);

  2. С помощью оценки соответствия или анализа уязвимостей (делается самостоятельно для себя, либо сторонней организацией с лицензией ФСТЭК на ТЗКИ).

Это разделение нашло свое отражение в упомянутых по тексту положениях Банка России. В порядке убывания сложности и цены указанные сценарии можно разместить следующим образом:

  1. Сертификация;

  2. Оценка соответствия;

  3. Анализ уязвимостей.

Разница между оценкой соответствия и анализом уязвимостей наглядно иллюстрируется рисунком 5. В первом случае необходима именно оценка соответствия, по множеству компонентов, формирующих указанный ОУД - по сути оценка всего SDLC. Во втором проработка лишь одного компонента, который зависит от построения SDLC, но является лишь малой частью того, что составляет целый ОУД.

При всех нюансах и вариациях имплементации необходимый минимум документации на приложение включает в себя:

  1. Описание архитектуры безопасности;

  2. Функциональные спецификации;

  3. Руководство пользователя по эксплуатации;

  4. Представление реализации;

  5. Проект объекта оценки;

  6. Задание по безопасности.

Для начала такого состава документов нам хватит. Что же касается качества реализации фреймворка и надежности заключений Оценщика, то независимо от выбранного сценария работ, это во многом зависит от соблюдения Заказчиком и Разработчиком установленных семейством 15408 пререквизитов. От выстроенного в организации SDLC и наличия проработанной документации на конкретный продукт. Здесь действует правило аналогичное любому типу анализа защищенности чем более прозрачным для проверяющих будет ПО, чем полнее окажутся его описания, чем более компетентным и проактивным будет Заказчик, тем больше недостатков и уязвимостей смогут найти проверяющие и тем качественнее окажутся их заключения. Увы, в реальной жизни, в силу дороговизны работ и сложности процесса, указанные выше пререквизиты часто либо отсутствуют, либо находятся в зачаточном состоянии.

Заключение

Это наш первый опыт популярного изложения вопросов комплаенса (или соответствия стандартам) для широкой публики и нам важно получить обратную связь, чтобы адаптировать будущие тексты под интересы читателей и сделать их полезнее. Расскажите, пожалуйста, в комментариях - что вам понравилось в первой статье цикла, а что нет? Какие специфические темы, вопросы или примеры из жизни вы бы хотели подробно разобрать в контексте темы цикла? А может быть вы уже активно работаете с ОУД и хотите поделиться решенными проблемами, замечаниями и наблюдениями? Помимо упомянутой во введении методички по вопросам ОУД, мы планируем серию сопутствующих вебинаров, содержанием которых могут стать ответы на ваши вопросы и демонстрация реальных кейсов внедрения фреймворка. Для желающих приватности адрес электронной почты для связи: aantonov@swordfishsecurity.com

Полезные ссылки и материалы по теме:

  1. https://malotavr.blogspot.com/ блог Дмитрия Кузнецова, эксперта Positive Technologies, одного из немногих специалистов, систематически рассматривающих вопросы сертификации ПО и анализа уязвимостей по ОУД4. Написал несколько материалов про требования ЦБ и ОУД4, см. статьи за 2019 год.

  2. https://www.youtube.com/watch?v=0ZoNdaoAeyc&t=658s обзорный вебинар компании RTM Group, посвященный особенностям фреймворка, с участием компании Safe Tech, описывающий реализацию фреймворка в отношении своего продукта.

  3. Переведенные стандарты:

    a. ГОСТ 15408-1-2012;

    b. ГОСТ 15408-2-2013;

    c. ГОСТ 15408-3-2013;

    d. ГОСТ 18045-2013;

    e. ГОСТ 57628-2017;

    f. ГОСТ Р 58143-2018.

  4. https://en.wikipedia.org/wiki/Common_Criteria Обзор лучших практик по безопасной разработке статья в вики для желающих самостоятельно углубиться в исторические предпосылки.

  5. Лучшие практики безопасной разработки:

    a. https://doi.org/10.6028/NIST.CSWP.04232020 обзор актуальных практик SDLC от американского института NIST Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF) от 23.04.2020;

    b. https://www.iso.org/standard/55583.html стандарт ISO/IEC 27034-3:2018 Information technology Application security Part 3: Application security management process;

    c. https://www.pcisecuritystandards.org/document_library стандарты PCI SSC линейки Software Security Framework:

    i. Secure Software Requirements and Assessment Procedures;

    ii. Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures.

  6. https://www.cbr.ru/information_security/acts/ Методический документ Банка России ПРОФИЛЬ ЗАЩИТ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций.

Приложение (список сокращений)

По тексту документа использованы следующие сокращения/условные обозначения:

  1. 382-П/Положение 382-П Положение Банка России от 9 июня 2012 г. 382-П О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств (актуальная редакция от 07.05.2018, действительно до 01.01.2022 года, отменяется 719-П);

  2. 719-П/Положение 719-П Положение Банка России от 4 июня 2020 г. 719-П О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств;

  3. 672-П/Положение 672-П Положение Банка России от 09.01.2019 N 672-П О требованиях к защите информации в платежной системе Банка России;

  4. 683-П/Положение 683-П Положение Банка России от 17 апреля 2019 г. N 683-П Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента;

  5. 684-П/Положение 684-П Положение Банка России от 17.04.2019 N 684-П Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций;

  6. 162-ФЗ/Федеральный закон 162 ФЗ Федеральный закон О стандартизации в Российской Федерации от 29.06.2015 N 162-ФЗ;

  7. АБС автоматизированная банковская система;

  8. ГОСТ Р национальный государственный стандарт Российской Федерации;

  9. ИБ информационная безопасность;

  10. ИТ информационные технологии;

  11. ОО объект оценки;

  12. ОУД оценочный уровень доверия (см. ГОСТ/МЭК 15408);

  13. ПО программное обеспечение, приложение;

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

  15. ISO/IEC International Organization for Standardization(ISO) and theInternational Electrotechnical Commission(IEC);

  16. SDLC - Software Development Lifecycle.

Соавтор: (Рустам Гусейнов, специалист по информационной безопасности).

Подробнее..

DevOps-практики Кто? Где? Сколько?

12.03.2021 10:04:49 | Автор: admin

DevOps-инженера ищут многие, но находят не все. Специалисты, умеющие внедрять DevOps-практики, последние 3 года являются одними из самых востребованных на IT-рынке. Спрос на них постоянно растёт. Заработная плата, несмотря на кризис, тоже не падает. Хорошие причины, чтобы задуматься, как прийти в эту профессию и каким образом в ней развиваться?

Специальность DevOps-инженера действительно появилась в IT-индустрии относительно недавно и быстро вырвалась в топ. Development Operations это, в первую очередь, набор практик, призванный улучшить и автоматизировать процесс доставки продукта до конечного пользователя, и он может быть полезен везде, где речь идёт о разработке приложений или управлении большим количеством серверов. Пожалуй, только небольшие команды могут позволить себе не выделять DevOps в отдельную функцию и обходиться исключительно своими силами.

Итак, какие задачи решает DevOps-инженер?

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

  • Обеспечение полного жизненного цикла продукта;

  • Подготовка различных окружений (разработка тестирование production) и обеспечение поставок продукта на эти окружения;

  • Обеспечение автоматического прохождения продукта через различные стадии непрерывной интеграции (CI) и непрерывной доставки (CD);

  • Виртуализация и управление инфраструктурой, мониторинг.

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

Исходя из направлений деятельности, на практике DevOps-инженер используют следующие инструменты:

  • CI/СD и интеграцию (Jenkins, TeamCity, GitLab, Bamboo);

  • Автоматизацию (Terraform, Puppit, Ansible);

  • Облачные платформы (AWS, Google Cloud Platform, Microsoft Azure, Huawei Cloud, Яндекс Облако, Mail.ru Cloud Solutions);

  • Мониторинг (Prometheus, Grafana, Zabbix, Nagios);

  • Системы логирования, трассировки (ELK Stack, Graylog, Gafana, Jaeger);

  • Контейнеризация и орекстрация (Docker, Kubernetes, Nomad).

Карьерная карта

В DevOps приходят из разных профессий. Основные доноры - это System administrator, Automation engineer, QA automation, Build Engineer/ Release Engineer, Developer. Представители этих специальностей уже обладают рядом навыков, которые необходимо развить и расширить.

Андрей Синицын, Head of IT Optimisation Departmen в ECommPay, рассказывает: Я занимаюсь компьютерами с середины 90-х я из того времени, когда эта профессия выбирала тебя. Передо мной никогда не стояло вопроса, чем заниматься по жизни. Сначала я работал программистом, потом понял, что мне интереснее эксплуатация, и ушел в DevOps. Живой продакшн это всегда интересно. И, на мой взгляд, интереснее, чем написание программы: ты видишь, как код эволюционирует, как он работает, как он выполняет (или, как это часто бывает, не выполняет) ту задачу, для решения которой был написан.

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

Сертификаты AWS, GCP, Azure, Kubernetes (CKA, CKAD) могут рассказать работодателю о том, что соискатель имеет навык работы с конкретными платформами, но, как правило, DevOps-инженером становятся только на практике.

Составляя идеальное DevOps-резюме, важно отразить в нём навыки, которыми вы владеете, задачи в рамках уже реализованных проектов, их особенности, зону ответственности; используемый стек технологий и, конечно, не забыть о soft-skills. Андрей Синицин подчёркивает, что для DevOps очень важны хорошие коммуникативные навыки, знание английского, обучаемость и out-of-box thinking стандартный набор для любой специализации в IT. Еще я бы добавил, что большое преимущество в DevOps дает понимание бизнеса (или стремление к этому). Эксплуатация никогда не зарабатывает деньги напрямую, и осознавать business value того, что ты делаешь, очень важно.

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

Кстати, нам вы также можете прислать резюме по этой ссылке.

Перспективы сегодня и завтра

DevOps-инженеры действительно зарабатывают больше всех в отрасли. В США, Канаде, UK заработная плата колеблется между 90 и 122 тысячами долларов в год. Что касается России, то в Москве работодатели готовы предложить такому специалисту в среднем 260 тыс. рублей в месяц (верхняя планка доходит до 350 тыс. ), в Санкт-Петербурге средняя зарплата составляет 200 тыс. рублей.

Есть и нематериальные мотиваторы. В частности, участие в масштабных проектах, решение сложных задач, возможность применять новые технологии и подходы. По словам Андрея Синицына, главный стимул, это создаваемый продукт, наверное. И интереса добавляет то, что этот продукт не коробочный. Участие в таких проектах всегда вдохновляет, появляется даже ощущение творца: когда команда создает шаг за шагом большую и сложную систему, которая обрабатывает огромное количество трафика, отвечая требованиям надежности.

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

Что касается возможностей карьерного роста, то для DevOps-инженера открыт путь к следующим позициям: Devops Team Lead, DevRel (Developer relations), Delivery Manager, Devops architect, Head of Engineering.

DevOps 2021: основные тренды

Анализируя 2020 год, можно заметить, что в центре внимания стала, прежде всего, безопасность. В том числе, безопасность IT-продуктов, поэтому одним из самых заметных трендов является DevSecOps и в целом SDLC (Security development lifecycle). DevSecOps подразумевает встраивание процесса безопасной разработки в процесс DevOps, интеграцию парадигм безопасности в каждый из этапов разработки.

Внедрение таких подходов, как DevSecOps, невозможно без следующего тренда автоматизации, одного из основных китов DevOps-практики. Скрипты, автоматизация, внедрение подхода IaC (инфраструктура как код) все это обеспечивает гибкость, скорость процессов разработки и поставки продукта.

Стоит также выделить глобальный тренд, который существует уже несколько лет это переход в cloud-native-среду и разработка приложений с учетом особенностей облачных платформ, считает Элиса Данильсон, консультант направления IT&Telecoms в Санкт-Петербурге.

Подробнее..

Перевод Что такое SDLC? Этапы, методология и процессы жизненного цикла программного обеспечения

02.10.2020 12:06:25 | Автор: admin
Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, жизненный цикл проекта охватывает всю деятельность проекта. Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?

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

Принципы работы SDLC и почему им пользуются


На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.



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

Я постараюсь абстрагироваться от тонкостей и предоставить общие примеры, подходящие для студентов и разработчиков ПО. Например, если вы по аналогии с Zoomshift пробуете создать приложение, рассчитанное на работников с почасовой оплатой, или приложение для учета времени, начать вам нужно будет с этапа анализа требований.

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

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

Мыслите за пределами обычного приложения по отслеживанию времени думайте о том, что вы хотите создать, чем вы хотите заниматься, а затем определите требования для решения связанных с этим проблем. Это и будет вашим началом.

Этапы SDLC и лучшие практики и методологии


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

  • Анализ требований отвечает на вопрос Какие проблемы требуют решений?
  • Планирование отвечает на вопрос Что мы хотим сделать?
  • Проектирование и дизайн отвечает на вопрос Как мы добьемся наших целей?
  • Разработка ПО регулирует процесс создания продукта.
  • Тестирование регулирует обеспечение качественной работы продукта.
  • Развертывание регулирует использование финального продукта.

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

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

Этап #1: Анализ требований


На этом этапе SDLC вам необходимо получить обратную связь и поддержку от соответствующих внутренних и внешних заинтересованных сторон. Вспомните мой недавний пример с разработкой приложения по учету времени: вам нужно будет широко задуматься о том, кто станут вашими потенциальными пользователями. Некоторые идеи будут включать ваших клиентов, дизайнеров, вашего начальника или других технических специалистов команды. В целом вы хотите ответить на следующий вопрос: Какие проблемы требуют решений? Быть внимательным и делать заметки будет очень полезно на этом этапе.

Когда полученные ответы вас удовлетворят, вы сможете перейти к следующей фазе.

Этап #2: Планирование


На этом этапе вы ищете ответ на следующий вопрос: Что вы хотите сделать? Этот вопрос может вдохновить вас на понимание юнит-экономики вашего плана (затраты и выгоды), факторов снижения рисков и ожидаемых стоимостей. По аналогии с планированием отпуска, вам нужно будет разложить ваши вещи и подумать о том, что следует взять с собой.

Хороший пример:

Я много читал об истории Инстаграма, чей этап планирования занял невероятно много времени. Это совпало с бурным ростом социальных сетей, поэтому взаимодействие пользователей с продуктом во многом все еще было неизвестно. Разработчики знали, что сильный первичный опыт (съемка, редактирование и обмен фотографиями) обеспечит рост, успех и высокую конверсию, а корректное планирование упростит проектирование, поэтому планировали соответствующе и тратили на дизайн много времени. Они всегда смотрели на шаг вперед и думали о будущем социальных сетей и электронной коммерции.

Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода к третьему этапу.

Этап #3: Проектирование и дизайн


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

Допустим, вы хотите создать безопасное, высокопроизводительное, эффективное и выдерживающее нагрузки приложение. Какой из этих четырех принципов наиболее для вас наиболее важен? Почему? Согласны ли с этим заинтересованные стороны из первого этапа? Важно обеспечить одобрение всех участников.

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

Этап #4: Разработка ПО


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

Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе и приступайте к делу.

Этап #5: Тестирование


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

Этап #6: Развертывание


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

Объединяя все вместе: подход SDLC


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

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

Разработка ПО может быть трудным, и в то же время полезным занятием.

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

Мой друг хотел основать лучшее рекламное агентство для Facebook и обратился ко мне и другим специалистам за помощью. Несмотря на его большие амбиции, я посоветовал ему воспользоваться фреймворком SDLC чтобы сначала провести анализ требований. Я спросил его: Какие проблемы ты хочешь решать? Чего хотят твои пользователи? И самое главное, как эта платформа поможет тебе достичь твоих целей?

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

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

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

Следовательно, цикл продолжается.

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

Фраза Создавать круто должна стать вашей путеводной звездой, а SDLC инструментом и помощником.
Подробнее..

У Вас проблемы с legacy значит, Вам повезло! Распил монолита на PHP

06.01.2021 06:14:44 | Автор: admin

Вступление

Меня часто просят рассказать о работе с legacy-монолитами. Про микросервисную архитектуру и переход на нее говорят много, но редко упоминают о том, что проекты приходят ней после многих лет роста с монолитным приложением. Учебники по решению проблем не пишут. Чтобы поменять архитектуру живого решения, надо пройти через несколько этапов. Автор работал с разными проектами - и с полноценным multitenancy service-oriented REST architecture в Oracle, и с огромным монолитом, в репозитории которого были коммиты за десять лет. Эта статья - о темной стороне, о legacy-коде, и практических решениях проблем с монолитными приложениями на PHP.

Причины появления legacy

Есть две основные причины появления legacy-кода.

Первая причина - выходят новые версии операционных систем, языков, браузеров, библиотек. Особенно актуальна проблема для мобильных приложений и скриптовых языков - с каждым выходом новой версии платформы нужно исправлять проблемы совместимости старого кода. Этот процесс стабилен и предсказуем на годы вперед.

Вторая - технический долг, который создается специально. Руководство сокращает срок разработки ПО за счет отказа от проектирования, автоматического тестирования или code review, одобряет сторонние библиотеки, которые не поддерживаются, а разработчики не документируют сложную логику. Это встречается повсеместно и не зависит от количества денег на счету компании. Не стоит ругать плохих начальников. У них есть весомые причины поступать именно так.

У продуктов есть жизненный цикл, период большого спроса на популярные товары длится три-четыре месяца. Все лучшее конкуренты скопируют и сделают еще лучше, поэтому компании вынуждены регулярно выпускать новинки. Чтобы поддерживать объем выручки, новые продукты и новые версии выпускают каждые несколько месяцев, так продажи нового цикла компенсируют снижение продаж по товарам в конце цикла. По три-четыре крупных релиза в год делают и Apple, и Marvel, и в Oracle на рынке enterprise SAAS тоже квартальный релизный цикл. При этом, рецепта успеха не существует. 97% стартапов выкидывают наработки по своему продукту, и пробуют делать что-то новое, прежде чем найдут такой продукт, который у них покупают. Поэтому затраты на разработку MVP в стартапах максимально сокращают.

У вас проблемы с легаси - значит, вам повезло!

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

Проблемы?

Не всегда плохой код создает проблемы. Например, знаменитый пакет Wordpress написан очень плохим кодом, но на его основе работает 38% интернет-сайтов. Стандартные работы выполняют специалисты на аутсорсинге по прайс-листу, а обновления устанавливаются по нажатию кнопки. Проблемы с Wordpress начинаются, когда в него добавляют нестандартный код, и автоматическое обновление становится невозможно.

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

Что делать тем, кому повезло?

Начинать надо с тестирования

Серьезные изменения кода всегда приводят к неожиданным проблемам. Без надежного тестирования сбои приложения приведут к потере выручки и снижению продаж.

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

Обновление версии языка

Через несколько лет после написания код становится несовместимым с актуальной версией языка, и это приводит к вороху проблем.

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

Составить список проблемы совместимости с новой версией PHP помогут утилиты статического анализа.

Rector поможет решить простые случаи несовместимости с новой версией, автоматически обновив часть кода.

Exakat поможет сделать анализ совместимости кода по версиям PHP, покажет список используемых расширений, проблемных участков кода, и поможет составить список задач на доработку.

Phan показывает использование в коде лексических конструкций, которые убраны из новых версий PHP.

Если для новой версии языка нет расширения, которое используется в приложении, участки кода с вызовами отсутствующих расширений придется переписать.

Обновление версии платформы или языка в таком случае выполняется достаточно быстро. Автор был инициатором обновления PHP с 5-ой версии на 7-ую для приложения с очень большим объемом кода, и эта задача была успешно выполнена командой за три недели.

Переход от монолита к сервисной архитектуре

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

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

К счастью, слона можно съесть по кусочкам - отделять от монолита модули, не переписывая код заново, зафиксировать API, а затем превращать их в сервисы. Сначала части кода приложения надо выделить в отдельные пакеты, а затем из пакетов можно будет создавать сервисы.

Перенос кода в пакеты открывает ряд возможностей:

  • можно сократить размер репозитория приложения,

  • разработчикам из разных команд можно предоставить только публичный API пакетов, и ограничить вызовы внутренних классов,

  • можно описать зависимости между своими модулями и использовать composer для управления зависимостями и версиями своих пакетов,

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

  • можно выпускать разные версии пакетов, и согласовать изменения API.

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

Разделение приложения на пакеты

Допустим, есть приложение на PHP, которое предоставляет клиентский API. Начинать любые изменения надо с процедур тестирования и релиза, которые включают план отката. Эти процедуры называют release, control, validation и DevOps. В активно развивающихся проектах тестирование и выкладка отработаны. В этом случае надо начинать разделять приложение с определения таких ограниченных контекстов, которые логично выделить в отдельные модули и сервисы.

Как пример, из приложения можно выделять обработку фотографий, аутентификацию пользователей, обработку платежей.

Создание отдельного модуля - это цикл из пяти подзадач:

1. Выбрать небольшой функционал для переноса в модуль - например, изменение размера изображений;

2. Определить API модуля - написать интерфейс, доступный приложению;

3. Написать или проверить приемочные тесты - например, на загрузку и валидацию изображения;

4. Скопировать в модуль старый код и инвертировать в коде модуля зависимости через границу модуля, без рефакторинга или переписывания всего кода;

5. Заменить в коде приложения прямые обращения к старому коду на вызовы сервиса из нового модуля; Для решения этой задачи используется две технологии: IoC-контейнер и менеджер зависимостей.

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

Начать создавать пакеты можно в локальном каталоге, а для полноценной сборки и развертывания стоит создать собственный репозиторий пакетов, такой, как Packeton, и перенести код модулей в собственные git-репозитории. Так же, можно использовать платный репозиторий Private Packagist.

Как создать composer-пакет в приложении и зарегистрировать его как сервис в IoC-контейнере, можно посмотреть здесь: до изменений, после изменений, diff.

В примерах используется composer для управления зависимостями пакетов и Symfony Dependency Injection как IoC-контейнер для сервисов. У Вас может быть другой контейнер. Если в приложении нет IoC-контейнера, придется делать рефакторинг и реализовать внедрение зависимостей. Простейший пример добавления IoC-контейнера в приложение.

Решение проблем со связанностью кода

Есть два типа связанности:

а) код будущего модуля содержит вызовы структур, которые описаны в других частях приложения

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

Рассмотрим случаи связанности кода, и варианты выделения модулей в пакеты без трудоемкого рефакторинга.

1. Расширение классов, реализация интерфейсов, использование трейтов, когда декларация структур используется через границу будущего модуля.

Приведу пример устранения связанности при наследовании, когда родительский и дочерний классы вызывают методы друг друга: результат, diff.

Основные алгоритмы расцепления связанности:

  • Сторонние библиотеки, которые используются в коде пакета, можно указать в зависимостях пакета.

  • Для интерфейсов, которые используются и в пакете, и в приложении, надо создать пакет контрактов, и указывать его в зависимостях.

  • Наследование от внешних классов с зависимостями надо превратить в композицию с помощью адаптеров, которые внедряются как сервисы.

  • Для защищенных свойств, которые используются в дочернем классе, надо сделать getter-методы, а для защищенных методов надо создать прокси-методы.

  • Наследование классов приложения от классов модуля стоит инвертировать в композицию с сервисом, который предоставляется новым пакетом.

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

2. Статические вызовы.

Синтаксис PHP допускает вызов статических методов у объектов как методов класса (пример). Если Вы выносите в пакет или обычную функцию или класс, у которого есть статический метод, эти функции/методы нужно добавить в публичное API пакета (пример, diff).

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

Ссылки: пример прямого статического вызова, пример инверсии зависимости статического вызова через внедрение сервиса, diff коммита.

Если несколько методов из разных классов используются вместе, для них можно создать сервис-фасад.

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

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

5. Использование глобальных констант и констант классов.

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

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

Ссылки: до изменений, после изменений, diff, декларация инъекции константы в контейнере.

6. Динамическое разрешение имен через строковые операции.

Пример: $model = new ($modelName . Class);

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

Эту конструкцию можно попробовать переписать в switch-структуру со статическим списком классов. К счастью, в приложениях подобный код встречается редко.

Оптимизация

В больших приложениях количество сервисов в IoC-контейнере бывает очень большим. Если в пакет выносится большой объем кода, у него могут быть десятки зависимостей. При обработке клиентских вызовов обычно создается только небольшая часть сервисов. Однако, при передаче зависимостей в конструктор класса контейнер будет создавать все перечисленные сервисы.

Есть несколько способов решения этой задачи:

  1. Сервисы, которые передаются в пакет, можно объявить как lazy.

  2. Объект API пакета можно объявить как Service Subscriber.

  3. Разделить API пакета на несколько сервисов.

Самый гибкий способ - это реализация Service Subscriber. Когда сервис объявляется подписчиком, можно реализовать в пакете вызов внешних сервисов по мере обращения к ним в пакете. Примеры: код до изменений, где используется один из нескольких классов, и код после переноса в пакет c инверсией зависимостей, где нужный сервис создается по требованию. Diff.

Service-Oriented Architecture

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

У каждого пакета зафиксирован публичный API. На основе этого API можно создать сервис с restful-протоколом. Код нового сервиса - это код пакета, вокруг которого написан достаточно стандартный роутинг, запись логов, и прочий инфраструктурный код. А в старом коде вместо кода пакета появляется адаптер для http-вызовов через curl.

При создании отдельных внутренних приложений-сервисов надо решить две задачи:

  1. Детальное протоколирование вызовов всех сервисов. Каждому клиентскому запросу надо присваивать уникальный ID вызова, который передается во все сервисы при вызовах внутренних API, и каждый вызов сервиса надо протоколировать. Надо иметь возможность отследить вызовы сервисов по цепочке.

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

Заключение

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru