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

Методология

Recovery mode Спецификация классификации методологии безопасной разработки

20.11.2020 04:16:11 | Автор: admin

Аннотация


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


Исследование рассматривается со стороны коммерческого сектора и самых эффективных форматов безопасной разработки. Исследование рассматривается с применением в практической части данных вариатив и их специфик в целом, и частном формате. Целью данной статьи является передача опыта и аналитика данных применяемых методологий, методов и средств разработки в защищенном исполнении. В статье представлен анализ, соответствующий разбор действующего рынка, законодательства, в части касающейся разработки информационных систем и сред в защищенном исполнении, которая именуются также как безопасная разработка, и которая с каждым днем набирает "критическую массу" популярности в различных отраслевых компаниях из-за ужесточения рекомендаций и требований регуляторов ИБ [1].


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


Введение


Данная статья базируется на принципах и процессах автоматизации ИС и сред организации, где рассматривается вопрос со стороны личной практики как руководителя, так и разработчика. В статье представлено практическое оценочное мнение и его эффективность. Частично статья касается вопроса со стороны OWASP TOP 10, но акцент на этом будет поставлен в последующих статьях. Стоит отметить, что не рассматривается практика сертификации, аттестации, выполнении требований опытных лабораторий, проектирования ПО по ПП РФ 608, включая приказ ФСТЭК России 55 и иных документов по безопасной разработке в данном направлении. Рассматривается формат представления универсальных характеристик разработки в безопасном исполнении, автоматизации, оптимизации, масштабируемости, адаптации БП (бизнес процесс), в формате ГОСТ Р 56939.


В коммерческом секторе РФ отсутствует установленное понятие для всех ветвей организации управления организации, в сфере прямо или косвенно касающихся IT и смежных с данными подразделений, такого как: ИС (информационная система) и среда. В том числе отсутствует понимание ее классификации в целом и частном порядке. В общепринятом представлении на рынке в потребительской сфере также отсутствует понимание построения структуры и непосредственно семантики работы ИС и сред. Данный общепринятый формат объясняется следующим образом, что методы, средства и методологии разработки по созданию, оптимизации, масштабируемости, итерационной интеграции, введению в промышленную эксплуатацию каноничны, во всем промежутке времени, которые парраллелелись по различным специфичным и обособленным между собою направлениям с применением разного рода подходов и методов для их реализаций. В последствии чего стали возникать угрозы, риски и последствия инцидентов для организаций, которые занимались обработкой, хранением информации, в том числе остро возник вопрос по ОИБ (обеспечение ИБ) информации: целостности, доступности, конфиденциальности. Этот вопрос также будет разобран отдельно в следующих статьях, где стоит отметить, что важнейшим аспектом стало на сегодня ОИБ КИИ РФ, также отдельно взяло направление по оценке рисков и инцидентов, в формате СУИБ (система управления информационной безопасности) и многое другое. В последствии данных форматов и форм-факторов возник вопрос безопасной разработки в организациях, где направление стало развиваться в геометрической прогрессии и набирать экспоненциальные обороты.


Информация и ИС в безопасной разработке


Приведем ИС в автоматизированном исполнении по типам, которые имеются на сегодняшний день и в связи с которыми разрослись методы, средства и методологии их реализации в разработке, проектировании и прототипировании, а именно:


  1. Автоматизированные системы управления:
    1.1. Техническими процессами;
    1.2. Предприятием;
    1.3. Производством.
  2. Системы автоматизированного проектирования и расчета, проектирования технологических процессов;
  3. Автоматизированные системы научных исследований;
  4. Автоматизированные системы обработки, передачи данных и БД, такие как:
    4.1. Автоматизированные информационно-поисковые системы;
    4.2. Автоматизированные системы информационно-терминологического обслуживания.
  5. Автоматизированные информационные системы, представляющие из себя агрегаторы информации;
  6. Автоматизированные системы технологической подготовки производства;
  7. Автоматизированные системы контроля и испытаний;
  8. Автоматизированные комплексные системы, методологические функциональные возможности специфик предприятий;
  9. Автоматизированные информационные системы общего назначения;
  10. Автоматизированные системы научно-технологической формации, оптимизации и сведения;
  11. Автоматизированные системы нормативно-правовой документации, нормативно-методического и методологического обеспечения управления предприятием;
  12. Автоматизированные обучающие системы организации;
  13. Автоматизированные системы виртуальной реальности;
  14. Автоматизированные профессионально ориентированные системы, экономические информационные системы, такие как:
    14.1. Бухгалтерские;
    14.2. Банковские;
    14.3. Рынка ценных бумаг;
    14.4. Маркетинговые;
    14.5. Продажные.
  15. Автоматизированные информационные системы профильного назначения по БП организаций.

Исходя из приведенного формата стоит дать определение термина информация, применяемого в безопасной разработке, касательно АИС (автоматизированная информационная система) в отношении действующего законодательства РФ, а именно:


  1. Это совокупность сведений, не зависимо от их формы, которые представляют из себя формализованный или не формализованный вид сообщения в независимой и ликвидной, либо не ликвидной форме;
  2. Это система комбинирования взаимодействующих элементов, организованных и структурированных форматов для достижения определенных поставленных целей и задач [2-5].

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


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


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


Далее отметим универсальные характеристики для безопасной разработки ИС, такие как:


  1. Основное назначения функционирования: сбор, хранение и обработка информации;
  2. Нацеленность функционирования АИС под потребительские нужны и цели, при необходимости реализации: объединения и распараллеливания функциональных возможностей АИС на подразделения и структуры, непосредственно самой организации;
  3. Представление проектирования интерфейса, в том числе соотношения UI/UX, прикладного программно-аппаратного обеспечения, как принцип минимальной содержательной достаточности для представление реализации взаимодействия функционирования АИС с исключением эксплуатационной возможности НДВ (не декларированных возможностей), в целом и частном.

Общая спецификация методологий по безопасной разработки ПО


Под спецификацией методологии понимается объединение перечня средств и методов, применяющихся в специфике деятельности организации, со стороны теории и практики разработки, включая прототипирование. Методологией является формат объединения методов, средств и технологий, применяющихся во время всего жизненного цикла процесса разработки и прототипирования ПО в организации. Данный формат является совокупностью практически выработанного и действующего формата в узконаправленной специфике организации для всей программно-аппаратной части и комплекса в целом. Следовательно стоит отметить, что также под методологией безопасной разработки ИС понимается организация процессов прототипирования и выстраивания ИС и сред, таких как: обеспечения управления процессами для гарантированного выполнения ТТ, ТЗ и реорганизации процессов [6-10].


Приведем список-перечень задач для достижения обеспечения действенности методологии безопасной разработки ИС и среды, состоящей из:


  1. Представления разработки и внедрения в промышленную эксплуатацию АИС, отвечающей целевым нуждам и спецификации по политикам работы организаций, в том числе ТТ и законодательных актов РФ, а также внутренних политик организаций и предъявленных к ним требований;
  2. Предоставления гарантий выполнения требований действующих регуляторов из специфики организации и приложений на разработку и интеграцию АИС с заданными параметрами, относительно ТТ и ТЗ в течение утвержденного календарного плана, а также оговоренного бюджета на разработку. Данный формат также может рассматриваться исходя из применяемых методов разработки ПО;
  3. Представления сопровождения технической и методологической части обучения, также модификации и масштабирования системы для обеспечения соответствия целевых нужд организаций, в том числе формата поддержания S.M.A.R.T.;
  4. Представления обеспечения разработки и внедрения в промышленную эксплуатацию АИС, отвечающей требованиям оптимизированности, переносимости, масштабируемости, адаптивности;
  5. Представления возможности вариативного использования в АИС разработанных средств и методов в программно-аппаратном обеспечении, СУБД, СУИБ и тому подобное. Отметим, что данный формат зависит от политик применяемых организацией, а также ее сферы деятельности.

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


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


  1. Классификацию по ядрам методологий, в которой утверждается, что имеет место быть ядру методологии с методами, которые уточняются дополнительными особенностями, а сами ядра определяются способами описания их алгоритмов, где к ним соотносятся:
    1.1. Методология императивного программирования, которая характеризуется принципом последовательного изменения состояния операнд итерационным образом, ориентированная на классическую модель Джона фон Неймана, получившей широкое практическое и теоретическое применение, с такими концепциями как:
    1.1.1. Метод последовательного изменения состояний, поддерживаемый концепцией алгоритма;
    1.1.2. Метод потокового управления на исполнение, в итерационном контроле.
    1.2. Методология объектно-ориентированного программирования (ООП), которая использует объектные декомпозиции. Отметим, что статическая структура ИС и сред описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами, как в UI/UX и системном программировании. Пример: инкапсуляция, то есть абстрактный тип данных, его наследование и полиморфизм, с применение таких методов как:
    1.2.1. Метод объектно-ориентированной декомпозиции, который заключается в выделении объектов и связей между ними, поддерживающийся концепциями инкапсуляции, наследования и полиморфизма;
    1.2.2. Метод абстрактных типов данных, который лежит в основе инкапсуляции, поддерживающийся концепцией абстрагирования;
    1.2.3. Метод пересылки сообщений, который заключается в описании поведения системы в терминах обмена сообщениями между объектами, поддерживаемый концепцией сообщения.
    1.3. Методология функционального программирования как способ составления программно-аппаратной части, в которой единственным действием является вызов функции, как вариативы, то есть способа расчленения программно-аппаратной части на отдельные сектора, где имеет место быть формат введения имени для функции и задания для него вычисляющего значения, применяемый с такими методами концепций как:
    1.3.1. Метод аппликативности, где: программно-аппаратная часть есть выражение, которое подставлено из функции к аргументу, состоящему из определения функции, представляющей собой вызов от другой функций и вложенной друг в друга, поддерживается концепцией функции;
    1.3.2. Метод рекурсивного поведения, который заключается в самоповторяющемся поведении, то есть возвращающемуся к самому себе, поддерживается концепцией рекурсии;
    1.3.3. Метод настраиваемости, который заключается в порождении новых программных объектов по специальному образцу, где значения соответствующих выражений применяется как порождающая функция к параметрам образца [11].
    1.4. Методология логического программирования, где программно-аппаратная часть содержит описание проблемы в терминах фактов и логических формул, а решение проблемы ИС и среды выполняется с помощью механизмов логического вывода, где применяются такие методы и концепции как:
    1.4.1. Метод единообразия, где используется применение механизма логического доказательства ко всей программе;
    1.4.2. Метод унификации, то есть механизм сопоставления с образцом для создания и декомпозиции структур БД.
    1.5. Методология программирования с ограничениями, при котором в ПО определяется тип данных для его решения, где предметная область шифруется на соответствующие ограничения значений искомого решения, которая находится в ИС и средах. В данной методологии предлагается двухуровневая архитектура, которая интегрируется как компонент ограничения программно-аппаратного компонента. В данном формате подразумевается описательная модель вычислений, где программа содержит описание понятий и задач в формате поддерживания концепции модели.
  2. Классификацию по топологической специфике самой методологий то есть форм-факторы топологии на базе методологии со способностью выбора самих методов для получения уточненного ядра, с такими методами и концепциями как:
    2.1. Последовательная декомпозиция алгоритма решения задачи сверху вниз в итерационной детализации, которая начинается с общей задачи и обеспечивает ее структурированность, которая поддерживается концепцией алгоритма;
    2.2. Метод модульной организации частей программы, где происходит разбиение программы на специальные компоненты, которые поддерживаются концепцией модуля;
    2.3. Использование структурного кодирования, где используется кодирование трех основных управляющих конструкций, которые поддерживаются концепцией управления.
  3. Классификацию по реализационной специфике методологии, где применяется использование каждого из ядер методологии с конкретной спецификой. В данной классификации определяется некоторая организация аппаратной поддержки, такая как: централизованная или параллельная, использующаяся для централизованных архитектур;
  4. Классификацию по смешанной методологии, которая включает объединение методов нескольких методологий, таких как методологии функционального и логического программирования;
  5. Классификацию по идейной задумке Петрова В.Н.: "Технологии разработки программного обеспечения", являющейся методологией RAD (Rapid Application Development). Данная методология носит наименование методологии быстрой разработки приложений. Целевая предпосылка в области инструментальных средств быстрой разработки приложений основана на таких элементах как:
    5.1. Объёмное положение разработчиков, которые разрабатывают АИС со всей спецификой и вариацией относительно ТТ, ТЗ. Например: минимальная группа разработчиков, представляет из себя от 2 до 10 человек, для большей части вариатива, может достигать до 100 разработчиков, такая специфика прослеживается в основном в игровой индустрии;
    5.2. Тщательная проработка производственного графа работ кадрового состава организации, его оптимизации и управления над ним, так же влияющий на календарный план разработки и прототипирования. Данный граф по временным отрезкам представляется от 2 до 6 месяцев, в среднем, но все зависит от целевых нужд организации для АИС, согласно ТТ и ТЗ.

Следует отметить, что приведенные методологии позволяют обеспечить безопасную разработку в организации по всем БП, что в свою очередь облегчит функционирование организации и управления кадровым составом, а это позволить повысить рентабельность и ликвидность конечного продукта. Данные форматы являются опосредованными и целостным, где позволят предотвратить методы и меры по OWASP TOP 10, что снизит риски и шансы возникновения инцидентов, а также их расследований по семейству ISO/IEK 27000.


Принципы выбора методологий в безопасной разработке


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


Следовательно, первоочередно стоит привести классическую (каноническую, монументальную) методологию, которая применяется исходя из наличия следующих принципов, таких как:


  1. Четкое понимание необходимого и конечного функционала, дизайна, прототипа интерфейса UI/UX и всей грядущей разработки АИС, то есть присутствует детализация специфики АИС. Стоит отметить, что она является четко регламентированной, с конечным конкретным ТЗ и ТТ, где описано: что и как должно работать;
  2. Формализованные целевые нужды конечного потребителя, тогда когда разработчики и руководящий состав, включая Заказчика представляют четкую "картину" в документированном виде, то есть: создается подробное ТЗ, где данная дефиниция регламентируется полноценным процессным состоянием каждого элемента в АИС, которая также содержит полноценное описание в цикле по специализированным алгоритмам, включая детализацию по UI/UX;
  3. Конечные требования к АИС являются стабильными, вследствие чего потребитель не дополняет условий по изменению функциональности АИС во время ее разработки, модернизации, исключая возможный формат блочного масштабирования в рамках текущих отношений;
  4. Представление итерационного процесса в формации аналитики, где проектирование и разработка ТЗ строго линейно.

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


Приведем далее более гибкую адаптивную методологию, которая применяется по следующим принципам, таким как:


  1. Предоставляются не понятийные, изменчивые требования к АИС;
  2. Потребителю предоставляется разрабатываемая АИС только в общих очерках, где предполагается внесение изменений функциональности или дизайна разрабатываемой АИС посредственно в сам момент произведения процесса разработки;
  3. Представление необходимости быстрого получения первых вариаций версионности продукта и дальнейшего масштабирования исходя от нужд организации и решений Digital, в момент работающего АИС;
  4. Представление решаемой задачи посредством программно-аппаратного комплекса АИС неэффективно поддается документированию по объективным причинам;
  5. Представление реализации всех требований к проекту, вновь внесенных в том числе, которые варьируется как добавочный ликвидный запас временного отрезка для разработки и прототипирования.

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


Следует предоставить и разобрать самые признанные и распространённые манифесты для представления гибкой безопасной разработки ПО, таких видов как:


  1. Manifest for Agile Software Development, который был разработан с целью альтернативного решения в плане использования канонической методологии для разработки ПО и поддержания максимизации выходных параметров для продукта из ресурсов организации;
  2. SCRUM реализуемая посредством создания "резервирования свойств системы", под резервом свойств понимается набор функциональных систем, которые необходимы для реализации, а функции описываются с помощью пользовательских сценарных подходов. Отличительная черта данной методологии представляется как проведение ежедневных митингов и обсуждений, которые называются stand-up, где в ходе совещания задаются каждому разработчику вопросы, такого типа:
    2.1. Что удалось выполнить для решения той или иной итерации за день?
    2.2. Какие были проблемы в моменте реализации?
    2.3. Что и как планируется сделать за сегодняшний день?
    2.4. Как происходит интеграция и оптимизация ПО в данном интервале?
    2.5. Иные виды вопросов исходя из практики организации.
  3. Экстремальное программирование: eXtreme Programming, XP, которое обладает простотой решения, интенсивной разработкой малыми группами состава разработчиков, спецификой активного общения, где также "бизнес" напрямую вовлечён в процесс разработки;
  4. Семейство методологий Crystal разработанная Алистером Коберном, который рассматривал процесс разработки как конечную целенаправленную игру, где утверждается, что у этой игры есть следующие цели, такие как:
    4.1. Основная цель, которая заключается в успешном закачивании разработки проектной части и внедрении в промышленную эксплуатацию;
    4.2. Вспомогательная цель, которая представляется в подготовке к следующей игре, для которой необходима определенного рода документация для разработки в виде оптимизированного и адаптированного исходного кода. Данная вариатива облегчает последующее масштабирование, а также поддержку продукта и тому подобное.
  5. Адаптивная методология, под наименованием: Adaptive Software Development, ASD это альтернатива традиционного ориентирования на процессы, посредством методов управления разработкой, где результат представляется как минимизация процессов при максимальном увеличении взаимодействий между людьми. Также данная методология базируется на принципах непрерывной адаптации, где постоянные вариативные изменения в проектной части становятся нормированной практикой. В данном случае жизненный процессный цикл: "Планирование Проектирование Конструирование" изменен на более адаптивный и динамичный, такой как: "Обдумывание Взаимодействие Обучение;
  6. Функционально-ориентированная разработка, под наименованием: Feature Driven Development, FDD, где та или иная функция реализовывается за две недели, если даже сценарии использования являются достаточно малыми, которые включают пять основных процессов:
    6.1. Разработка общих моделей;
    6.2. Составление списков необходимых функций для ПО;
    6.3. Планирование исполнительных работ над функциями;
    6.4. Проектирование самих функции;
    6.5. Конструирование самих функции.

Отмечу, что данные манифесты являются применимыми, но не всегда корректно, так как имеется практика введения только положительных методов из них, а не полноценного формата контроля и управления, где руководящий состав организации считает, что это будет наиболее эффективно, нежели чем процесс полноценной интеграции конкреной системы, что приводит к не корректному взаимодействию внутри команды и процесса разработки дающего только отрицательный характер влияния на "бизнес". Для безопасной разработки ПО считаются важными данные аспекты методологии, управления, разработки и проектирования, так как они позволяют решить подавляющую часть проблем связанных с рисками и инцидентами ИБ, в том числе выполнить и перекрыть требования, и рекомендации регуляторов ИБ и обезопасить конечный продукт, а также "бизнес". В том числе учитываются специалисты по PenTest, DevSecOps и так далее, так как профильные специалисты с опытом смогу предоставить ОИБ организации [13-15].


Выводы


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


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


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


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


P.S.: если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.


Литература

[1] Федеральный закон Об информации, информационных технологиях и защите информации 149 ФЗ от 27 июля 2006 года;
[2] ГОСТ Р 6.30-2003 Унифицированная система организационно-распорядительной документации;
[3] ГОСТ Р 7.0.8.-2013 "Делопроизводство и архивное дело Термины и определения";
[4] ГОСТ 6.10.4-84 Придание юридической силы документам на машинном носителе и машинограмме, созданным средствами вычислительной техники;
[5] ГОСТ 6.10.5-87 Унифицированные системы документации. Требования к построению формуляра-образца;
[6] Доктрина информационной безопасности;
[7] Федеральный закон от 21 июля 1993 года 5485-1О государственной тайне;
[8] О закрытом административно-территориальном образовании;
[9] Астахова Л.В. Теория информационной безопасности и методология защиты информации: методическое пособие / Л.В. Астахова. Челябинск: Изд-во ЮУрГУ, 2007. 359 с.;
[11] Юдин, Э.Г. Методология науки. Системность. Деятельность / Э.Г. Юдин. М.: Эдиториал УРСС, 1997. 246 с.;
[12] Князева Т. Отечественные системы автоматизации делопроизводства;
[13] Комарова А.В., Менщиков А.А, Коробейников А.Г. Анализ и сравнение алгоритмов электронной цифровой подписи ГОСТ Р 34.10-1994, ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012// Вопросы кибербезопасности. 2016. 1 (19). С. 51-56;
[14] Боровский А. С., Ряполова Е. И Построение модели системы защиты в облачных технологиях на основе многоагентного подхода с использованием автоматной модели;
[15] Захаренков А.И., Бутусов И.В., Романов А.А., Степень доверенности программно-аппаратных средств как показатель качества замещения импорта // Вопросы кибербезопасности. 2017. 4 (22). С. 2-9.

Подробнее..

7 soft skills, которые нужно начинать прокачивать уже сейчас

22.10.2020 12:07:47 | Автор: admin
image

Быть программистом в 2020 году не то же самое, что десять лет назад. Мир постоянно меняется, и многие из умений, которые были важны тогда, со временем отошли на второй план. А какими навыками должен обладать разработчик, чтобы оставаться востребованным специалистом, например, через пять лет? Если у вас их нет, возможно, стоит подумать над их развитием уже сейчас?

Я Анастасия Горелова, руководитель программ обучения Хаб Знаний МойОфис. Занимаюсь проектированием и реализацией программ развития hard и soft skills наших сотрудников, обучаю коллег, партнеров и клиентов работе с продуктами МойОфис, а также продвигаю наши образовательные проекты в школах и университетах.

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

1. Комплексное решение проблем


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

image

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

Вопрос для самопроверки:

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

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

2. Умение убеждать


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

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

Вопросы для самопроверки:

  • Замечали ли вы, что вас перебивают на совещаниях? Было ли ощущение, что вас никто не слушает?
  • Стараетесь ли вы приводить наглядные кейсы, когда отстаиваете свою точку зрения?
  • Как вы начнете рассказ о себе? Отрепетируйте небольшой спич.
  • Вспомните случай, когда после разговора с вами коллега менял свое мнение. Что именно помогло вам переубедить его?
  • Как вы реагируете на возражения?

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

3. Навыки сотрудничества и работы в команде


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

image

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

Вопросы для самопроверки:

  • Вам нужно заговорить с коллегой, которого вы не знали ранее. С чего вы начнете?
  • Один из участников команды раз за разом сдает работу с ошибками. Как вы поступите?
  • Какие слова вы подберете, чтобы критика прозвучала доброжелательно?
  • Отмечаете ли вы успехи коллег и говорите ли о них публично?
  • Что помогает вам почувствовать настроение собеседника и настроиться на его волну?

Для развития навыков сотрудничества в некоторых командах мы практикуем метод ротации, когда разработчик из одного проекта МойОфис на время переходит в смежный. Это не только позволяет попробовать себя в новом деле, но и прокачивает умение общаться с коллегами, помогает не закисать и переключаться с рутинной работы на новые задачи. Если есть запрос, мы организовываем специализированные курсы для развития личных и профессиональных навыков. Кроме того, всем нашим руководителям мы настоятельно рекомендуем на регулярной основе проводить one to one встречи с каждым членом команды, чтобы участники могли скорректировать планы, задачи, выстроить доверительное общение и на ранних этапах предугадать появление ошибок. На таких встречах сотрудник учится задавать правильные вопросы, слышать обратную связь, осваивает навыки конструктивно обсуждать взаимодействие в команде.

4. Умение планировать свою работу


Банальный тайм-менеджмент на самом деле не такой уж банальный. Период вынужденной самоизоляции 2020 года показал, что навык управления временем чрезвычайно важен в работе каждого. Уверены, что и через пять лет он будет по-прежнему актуален. Работодатели ценят специалистов, которые умеют планировать, дают точные оценки сложности задач и придерживаются сроков независимо от используемого языка, технологий и методологий.

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

Вопросы для самопроверки:

  • Вас просят назвать сроки готовности проекта. Чем вы будете руководствоваться при оценке?
  • Разгар рабочего дня, и вдруг коллега присылает вам ссылку. Вы знаете, что там полезная и важная статья. Как вы поступите?
  • Составляете ли вы рабочие и личные планы на день/неделю/месяц? Как много из них удается выполнить?
  • Знаком ли вам метод планирования времени матрица Эйзенхауэра?
  • Знаете ли вы, сколько времени у вас в среднем уходит на каждый тип задач?
  • Сколько минут / часов в день вы проводите в социальных сетях? Отслеживаете ли вы каким-либо образом эту статистику? Используете ли тайм-трекеры?
  • Практикуете ли отдых от соцсетей и интернета, digital detox?

Для планирования работ и фиксации промежуточных вех проекта некоторые отделы МойОфис используют методологию Scrum и обучают ей новых сотрудников, чтобы группа работала слаженно. Часть команды в Москве ориентирована на освоение стандартных методик управления проектами по методологии PMI PMBoK. Мы в Хабе Знаний в свою очередь пополняем библиотеку компании материалами по тайм-менеджменту коллегам доступны актуальные новинки, техники из которых они могут начать внедрять сразу после прочтения.

5. Критическое мышление


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

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

Вопросы для самопроверки:

  • Задумываетесь ли вы при чтении материалов в интернете о том, кто и с какой целью их публикует?
  • Как вы определяете, какой информации можно доверять? На какие критерии вы опираетесь при выборе источников информации?
  • Проверяете ли вы адреса сайтов и защищенность соединения при переходе по незнакомым ссылкам?
  • Есть ли у вас список доверенных источников информации?

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

6. Постоянное обучение long life learning


Многие ведущие компании стремятся нанимать full-stack разработчиков, которые свободно работают с разными технологиями и платформами. Такие специалисты понимают принципы любой разработки, начиная с уровня ядра сети и заканчивая уровнем интерфейса. Этого невозможно достичь, если не взять за правило постоянно изучать новое. Востребованного разработчика определяет не только владение редким стеком, но и способность легко переключаться между разными языками и стремление изучать новые инструменты каждый день.

image

Пример: хотя Java и C# уже несколько лет занимают значительную часть рынка, IT-компании все чаще используют более новые технологии (Kotlin, Swift и др). И логично, что разработчики, хорошо владеющие несколькими языками, дадут фору тем, кто знаком с одной-двумя технологиями. Через пять лет наверняка появятся новые стеки, поэтому чтобы оставаться востребованным, важно постоянно учиться и уметь выбирать подходящий инструмент для решения конкретной задачи, основываясь на комплексном анализе факторов.

Вопросы для самопроверки:

  • Участвуете ли вы в развитии open-source проектов? Сколько коммитов вы сделали за прошедший год? Сколько создали багов и предложений в трекере? На сколько вопросов ответили?
  • Как давно вы изучали незнакомую для себя технологию?
  • Как вы поступите, если узнаете о появлении нового языка, который набирает популярность?
  • Как вы реагируете, если вам предлагают пойти на обучающее мероприятие?
  • Какие профессиональные конференции вы посещаете?
  • Чему вы научились в вашей профессиональной области за последние полгода?

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

7. Соблюдение work-life balance


Cоблюдение work-life balance и ваше самочувствие прямо влияют на продуктивность: тот, кто заботится о себе, обычно живет дольше, работает эффективнее и успевает уделять должное внимание другим важным делам. Тема здоровья тесно связана со всеми сферами жизни, в том числе с работой. Не буду ничего говорить про биохакинг и вживление чипов под кожу (это тема отдельного поста а то и не одного), этот пункт больше про внимание к телу, к психоэмоциональному состоянию, а еще о том, что разделение личной и профессиональной жизни помогает им взаимно друг друга поддерживать. Старайтесь быть терпимее к другим, особенно если их точка зрения противоречит вашей, выражайте чувства без вреда окружающим и осознавайте, на что вы можете повлиять, а на что нет. Найдите хобби по душе и помните, что от того, как организована ваша жизнь после работы и учебы, будут отчасти зависеть и карьерные успехи.

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

Вопросы для самопроверки:

  • Когда вы последний раз проходили комплексное обследование?
  • Что вы делаете для того, чтобы ваше питание было сбалансированным?
  • Сколько часов в сутки вы спите? Высыпаетесь ли вы? Если нет, что вы можете сделать уже сейчас для улучшения качества вашего сна?
  • Утром вы чувствуете себя простывшим, но нужно ехать на работу. Как вы поступите?
  • Работаете ли вы в отпуске? Доделываете ли проекты в выходные? Пишете ли в рабочие чаты по вечерам?
  • Какие у вас хобби? Давно ли вы увлекались чем-то для себя новым?

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

Вместо послесловия


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

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

Свидетели DevOps мифы и байки про девопсов и тех, кто их нанимает

25.02.2021 10:21:06 | Автор: admin

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

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

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

Трудности перевода

Справедливости ради оговорюсь, что DevOps это не название профессии, а методология. Она описывает набор подходов и практик, которые помогают командной разработке. Но штампы преследуют нас повсюду. И вот уже не режет слух, когда уважаемый заказчик, представляя свою команду на установочном звонке, говорит: А это Антон, наш девопс. Знакомьтесь, DevOps. Человек и пароход.

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

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

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

Байка про хромого девопса

Недавно нас позвали на помощь в один проект, где стояла, на первый взгляд, простая задача. Web-приложение работало через web-сокеты, но было развернуто внутри периметра, а на фронте стоял ISPManager, который в качестве reverse proxy использовал apache. Юный девопс, работавший в этом проекте, перепробовал все примеры конфига апача, которые нашел в Гугле, и вконец разочаровавшись в его поисковых способностях, перешел уже было к Яндексу, но тут менеджер проекта забил тревогу. На задачу к тому моменту было потрачено 72 часа. 72 часа, Карл! Кто вам сказал, что методология DevOps ускоряет разработку и сокращает time-to-market? ;)

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

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

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

Про технологии

DevOps это про культуру и философию совместной работы, но с этим понятием также сопряжен определенный технологический стек. Скорее всего я не ошибусь, если скажу, что какие-нибудь NetApp, Cisco, AIX или MS SQL воспринимаются как старый добрый олдскул (хотя это не совсем так, и классические вендоры делают гигантские шаги в новом направлении), а вот, скажем, Docker, Ansible, Jenkins и Prometheus в нашем сознании прочно ассоциируются с DevOps, SRE и новыми веяниями.

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

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

И отдельная боль это сеть. В сети надо разбираться, владеть инструментами диагностики. Сеть не зависит от платформы, она есть везде и напрямую (а порой больно) влияет на работоспособность и производительность всего остального. Когда человек, грезящий себя девопсом, наивно полагает, что надо установить свежую версию Kibana, потому что она умеет конвертировать адреса IPv6 в IPv4 это звучит как анекдот. Но потом он, например, берет и орудует с сетью вот так:

или вот так:

Дальше хочу немного заострить внимание на двух технологиях, которые почти стали синонимами DevOps.

А давайте-ка все распилим на микросервисы, засунем в Docker и запустим в Kubernetes

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

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

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

Вот, кстати, символичный фрагмент одного из скриптов по деплою:

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

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

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

- А у вас есть kubernetes?

- Да, конечно, ну как у всех! Как полагается.

- А зачем?

- Ну как это зачем? Это же

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

Я считаю себя евангелистом подхода Infrastructure as Code (IaC). Мне спокойно только тогда, когда продукт не просто освоен, а когда его развертывание и настройка автоматизированы. Специально не добавляю слово документированы, потому что декларативный характер инструментов IaC что приятно во много порождает автодокументируемый код.

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

Для иллюстрации пример, который подвернулся на скорую руку это варианты, как можно запустить телеграм-бот для Alertmanager (взято отсюда).

Просто через docker run:

docker run

docker run -d \

-e 'ALERTMANAGER_URL=http://alertmanager:9093' \

-e 'BOLT_PATH=/data/bot.db' \

-e 'STORE=bolt' \

-e 'TELEGRAM_ADMIN=1234567' \

-e 'TELEGRAM_TOKEN=XXX' \

-v '/srv/monitoring/alertmanager-bot:/data' \

--name alertmanager-bot \

metalmatze/alertmanager-bot:0.4.3

С помощью docker-compose

docker-compose

networks:

alertmanager-bot: {}

services:

alertmanager-bot:

command:

- --alertmanager.url=http://localhost:9093

- --log.level=info

- --store=bolt

- --bolt.path=/data/bot.db

environment:

TELEGRAM_ADMIN: "1234"

TELEGRAM_TOKEN: XXXXXXX

image: metalmatze/alertmanager-bot:0.4.3

networks:

- alertmanager-bot

ports:

- 8080:8080

restart: always

volumes:

- ./data:/data

version: "3"

А вот тот же сервис в Kubernetes

кубер

apiVersion: v1

items:

- apiVersion: v1

data:

admin: MTIzNA==

token: WFhYWFhYWA==

kind: Secret

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

type: Opaque

- apiVersion: v1

kind: Service

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

ports:

- name: http

port: 8080

targetPort: 8080

selector:

app.kubernetes.io/name: alertmanager-bot

- apiVersion: apps/v1

kind: StatefulSet

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

podManagementPolicy: OrderedReady

replicas: 1

selector:

matchLabels:

app.kubernetes.io/name: alertmanager-bot

serviceName: alertmanager-bot

template:

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

containers:

- args:

- --alertmanager.url=http://localhost:9093

- --log.level=info

- --store=bolt

- --bolt.path=/data/bot.db

env:

- name: TELEGRAM_ADMIN

valueFrom:

secretKeyRef:

key: admin

name: alertmanager-bot

- name: TELEGRAM_TOKEN

valueFrom:

secretKeyRef:

key: token

name: alertmanager-bot

image: metalmatze/alertmanager-bot:0.4.3

imagePullPolicy: IfNotPresent

name: alertmanager-bot

ports:

- containerPort: 8080

name: http

resources:

limits:

cpu: 100m

memory: 128Mi

requests:

cpu: 25m

memory: 64Mi

volumeMounts:

- mountPath: /data

name: data

restartPolicy: Always

volumes:

- name: data

persistentVolumeClaim:

claimName: data

volumeClaimTemplates:

- apiVersion: v1

kind: PersistentVolumeClaim

metadata:

labels:

app.kubernetes.io/name: alertmanager-bot

name: alertmanager-bot

namespace: monitoring

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 1Gi

storageClassName: standard

kind: List

Если решение все же принято, вам предстоит перелопатить горы документации, написать тонны yaml-a, мучительно искать, где пропущен отступ, по 10 раз пересобирать контейнеры. И в этом момент вы еще и не знаете, что через пару недель пройдете новый круг ада, подстраивая ваш деплоймент под Pod Security Policy и разные энтерпрайзные фичи. Конечно, когда вы это дотащите до конца, вы получите красивый сервис, который легко скейлится, автоматически перезапускается при сбоях, который можно обновлять, используя, например, канареечные релизы или какой-нибудь blue-green deployment.

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

Автоматизация как истинный путь джедая

Наши бэкапшики помнят один случай, как сотрудник заказчика собирался в консоли что-то удалить то ли ненужный симлинк, то ли копию конфига. А его то и дело дергали. По воле случая в один момент так сошлось, что товарищ успел набрать rm -rf /oradata, работая от рута, потом чихнул, что в свою очередь пробудило в его организме рута позывы на исход жидкости, а по дороге обратно он зацепился языками с товарищами. Когда он вернулся на рабочее месте, его экран спал. Не будучи в силах терпеть проделки этого вечно дремлющего устройства и дабы преподнести ему урок бодрости, товарищ решительно разбудил его точным ударом в Enter. В общем, когда все делаешь руками, нелепые вещи случаются сплошь и рядом.

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

Самое плохое в автоматизации это время, которое надо на нее потратить. И самое хорошее в ней тоже время, которое она впоследствие высвобождает. Например, пару лет назад нам потребовалось в нашем облаке IaaS развернуть инфраструктуру под нового e-commerce заказчика. Архитектура проекта: кластер БД, пул серверов приложений, распределенное хранилище, слой кэширования, сетевые балансировщики, WAF, ну и стандартная обвязка в виде телеметрии, СРК и сбора логов с визуализацией. Конечно, виртуальные машины мы давно создавали при помощи terraform, благо под наше облако можно использовать AWS-провайдер, так как мы по API совместимы. Программные компоненты и раньше ставили через ansible, и опыт настройки всего по отдельности, в общем, был. Но мы задались целью описать инфраструктуру проекта в виде единого пайплайна. На это ушло время, ну и до сих пор части этой автоматизации совершенствуются, так как еще много где были нами после переиспользованы.

Когда нам позже подвернулся аналогичный проект, различия описывались на уровне файла ответов. Мы развернули проект за 2 дня, причем большую часть времени занял перенос данных. В Gitlab CI запускался pipeline, который заполнял переменные для terraform, который затем запускался runner-ом. Тот создавал в облаке сети, диски и ВМ. ВМ запускались с cloud-init, который ставил внутрь puppet agent, который после старта связывался с foreman, забирал настройки для своей роли и деплоил все ПО. Через service discovery подключался мониторинг всех служб, везде встал и настроился filebeat, а бакап полился в S3. Voila! Все быстро и четко, без ошибок и ручных тестов на каждом шаге.

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

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

  • осмысленный сайзинг ресурсов;

  • отдельные точки монтирования (отдельный диск/раздел) под данные приложений и все, что может быстро пухнуть;

  • синхронизацию времени по ntp;

  • переход на использование ключей вместо паролей в ssh;

  • настроить ротацию всех логов;

  • иметь автоматический механизм обновления протухающих SSL-сертификатов

  • покрыть мониторингом все ключевые показатели жизнеспособности системы и не забыть про алерты;

  • если в системе есть данные, иметь автоматический бэкап по расписанию, и не хранить его рядом с данными.

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

Эти простые меры по принципу Парето составляют не более 20% действий по первичной настройке, но дают 80% вклада в стабильную и автономную их работу в будущем.

Если у вас уже есть provision-система, то следом можно подключить инструмент IaC, и накатывать все эти настройки всегда по умолчанию, через какой-нибудь базовый профиль. Я в такой профиль еще включаю набор обязательных утилит, чтобы, к примеру, в экстренной ситуации не оказалось, что в системе нет lsof, tcpdump и т. п.

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

Как не стать героем баек

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

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

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

И напоследок завет работодателям

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

Если вам понадобился девопс, у вас вероятно уже есть разработка. Задачи, которые выполняет девопс это та же разработка, только инфраструктуры и процессов, поэтому к ней в целом применимы те же правила. Над девопсом должен быть senior или тимлид, который через систему контроля версий делает code review, проверяет и одобряет PR/MR. И совершенно точно не стоит доверять архитектурные вопросы человеку без подтвержденного архитектурного опыта. Лучше поищите стороннюю экспертизу для подстраховки.

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

В этом месте ставлю не точку, а многоточие, так как тема неисчерпаемая и весьма холиварная. Комментарии, как говорится, покажут :)

Подробнее..

Новая методика обучения программированию или зачем делать ещё один курс?

21.04.2021 20:21:36 | Автор: admin

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

Почему? Дело в том, что большинство курсов создаются не с целью решить вашу проблему, а по другим причинам. И речь даже не о деньгах.

99% курсов в Интернете создают у вас ощущение прогрессии, того, что вы стали специалистом

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

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

Как обычно преподают программирование (и не только)

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

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

Во-вторых и с практикой не все так просто. Ведь она обычно привязана к той теории, которую блоками выдают в курсе. То есть человек может пройти курс, успешно в одиночку решить все практические задания, сделанные под условия а потом прийти на работу и не справится с написанием даже простой программы! Нельзя учить программистов на материалах, написанных при Java 6, а потом попросить их написать что-то на Java 16.

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

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

Как обучать эффективнее в новых условиях?

С этим вопросом мы удалились на подумать и в течении долгого времени не вышло ни одного нового курса от нашей команды. Но результат того стоил мы внедрили в обучающий процесс новую методику, основанную наUODP(User Oriented Development Process), которая ориентируется на потребности студентов.

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

  • Программа максимально сосредоточилась на практике, минимум теоретических основ;

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

  • И самое главное. Все ученики могут делится своими решениями проблемы и обсуждать их.

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

Даже при одинаковых запросах в Google два человека получат разный результат, кликнут на разные ссылки. После этого они по-своему решат задачу и поделятся этим решением со всей группой! Т. е. ученик вместо одного правильного решения проблемы получит множество по-своему интересных, до которых сам бы возможно не дошел. А потом сможет в своей практической работе применить то, которое максимально подойдет. Знания взаимодополняют друг друга.

Насколько этот подход оказался эффективным?

Говоря честно, этот подход конечно оказался сложнее прежней схемы но показывает невероятную эффективность. В обычном курсе 10% учеников не заканчивают курс, 75 справляются, но не получают желаемого результата, и только 15% достигают того, что хотели: получают новую, интересную им профессию.

В рамках эксперимента мы организовали серию, по началу совсем бесплатных групп организованных по этой новой методике. В новой схеме обучения расклад интереснее: около половины участников курса не проходят его с первого раза. Но при этом более 40 (!)% говорят да, мы получили то, что хотели от этого курса. Со второго раза курс проходят больше 60% участников цифра уже выше.

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

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

Если вам интересно узнать подробнее о нашем процессе обучения заходитек нам в Discord там живое общение студентов и печеньки.

Подробнее..

Бережливый стартап или как мы используем концепцию Lean Startup в своих проектах

02.03.2021 08:14:22 | Автор: admin
Создание чего-то нового дело всегда рискованное. Как и многие люди до вас, вы пишете бизнес-план, предлагаете его инвесторам (либо роетесь в собственном кошельке), набираете людей, начинаете разрабатывать продукт, тратите тысячи человеко-часов. А потом, спустя месяцы разработки (а иногда и годы) получается, что вы всё это время усиленно делали продукт, который никому не нужен. Вот вообще. А деньги и время уже потратили.

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

В этом посте расскажем, как мы в компании Автомакон применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваемся и как с ними справляемся.

У ВкусВилл есть книжный клуб для сотрудников, в рамках которого часто обсуждаются те или иные книги. И нас часто приглашают поучаствовать в нем. На одном из таких собраний обсуждалась книга Эрика Риса Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.

image

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

Работа по классике


С самого начала проекта Тилси началось выстраивание платформы с космическими требованиями:
  • Высоконагруженная система;
  • Всё пишем на Golang;
  • Создание теоретических бизнес-процессов.

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

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

Работа по линам


Вот что сделали:

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

Кроме этого мы использовали подход Lean Startup в Зеленой линии, совместном проекте ВкусВилла и Перекрестка по запуску новой линейки натуральных молочных продуктов с ультракоротким сроком годности. Он так и назывался, Маркет. Зеленая Линия В рамках проекта мы протестировали много гипотез. Подтвержденные гипотезы ценности позволили сэкономить кучу денег и времени, а неподтвержденные не тратить ресурсы на тупиковые направления.

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

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

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

На чём стоит Lean Startup


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

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

Не дешево, а экономно


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

Каждый рубль, каждый час сотрудника должны тратиться с умом. Здесь не получится взять и бросить команду на создание какой-то части продукта, сжечь пару КАМАЗов денег в процессе, а через полгода понять, что не взлетело. И пойти делать новый продукт.

Суть подхода


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

Это важно, ведь это касается интереса людей к продукту, его нужности, как следствие спроса. Вы можете сделать великолепный по своим ТТХ смартфон. Открыть кофейню с лучшим кофе в мире.

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

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

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

Соответствует ли продукт нуждам потребителей?

На самом деле он нужен, или команда убеждает себя в этом и делает неправильные выводы? Тут нужно подходить к делу максимально объективно, абстрагируясь от своего отношения к продукту.

Как потребители решали подобную проблему раньше?

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

Какие издержки потребители сегодня несут из-за этой проблемы?

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

Нужно ли адаптировать или изменить ваш продукт?

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

Если точно всё ОК, то переходим к пятому вопросу.

Готовы ли вы масштабировать его?

Допустим, все здорово, и у вас или сразу получилось что-то отличное, или вы вовремя допили продукт до такого состояния. Надо быть готовым к масштабированию продукт-то успешный (если вы честно ответили на вопросы выше). Значит, спрос будет. И он будет увеличиваться.

Осилит ли компания масштабирование? Хватит ли времени и денег, рук разработчиков, потянет ли инфраструктура возросшую нагрузку?

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

Непрерывность развития


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

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

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

Гибкость


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

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

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

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

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

А руль дает вам возможность подстроиться под то, что уже точно случилось

Погодите, это же постоянный MVP


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

Это и есть бережливость.

Что еще важно


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

Работайте с обратной связью. Это постоянный статус вашего проекта.

Эксперименты. Не бойтесь проводить их снова и снова. Посмотрите, сколько больших компаний вокруг используют A\B-тестирование. Вспомните, сколько разных версий интерфейса Facebook прямо сейчас показывается различным сегментам пользователей. Это все эксперименты, это все проверки тех или иных гипотез.

Это постоянные инновации, которые обеспечивают постоянный прогресс.

Итого


Настоятельно рекомендуем обратить внимание на концепцию Lean Startup. Из IT вы или нет, большие у вас бюджеты или собственные сбережения на продукт, методология пригодится.

Вот наши выводы от использования подхода на практике:

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


Кстати, мы сейчас активно расширяем команду, которая активно применяет Lean-подход. Вот тут можно посмотреть полный перечень вакансий hh.ru / наш карьерный сайт

Будем рады ответить на ваши вопросы.
Подробнее..

Категории

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

  • Имя: Макс
    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