Содержание. Priv-8.com Введение. Производительности. Системы контроля версий. Координация команды. Системы управления проектом. Проблема камаза. Документирование проекта. Поддержка и общение с клиентами. Непрерывная разработка (Continuos Integration / CI ). 1 Введение. Вашему внимаю предлагаю статью по организации работы сервиса и координацы участников команды. Учитывая, что последние несколько лет, я занимался руководством разработкой коммерческого ПО в небольших и крупных компаниях, большинство информации основано на личном опыте. Хочу поделиться опытом с Вами, возможно все изложенное выше излишне, а большинство информации доступно в открытом доступе. Но тем не менее на черном рынке услуг, я не встречал ниодного сервиса, на поддержку которого не было бы жалобы. А также сервиса который после длительного простоя мог бы «реанимироваться» другими участниками. Вот небольшая цитата из новостей с securitylab.ru Fortinet представила отчет «Fortinet 2013 Cybercrime Report», в котором рассказывается о переходе киберпреступников на новый уровень. Так, злоумышленники используют бизнес-модель «Crime-as-a-Service» («Преступление как сервис») для оказания своеобразных услуг. Подробнее: http://www.securitylab.ru/news/437126.php Предлагаю перенять опыт у компания по разработке легального программного обеспечения. И так к делу. 2 Производительности. Системы контроля версий. Ни для кого не секрет, что компьютерные технологии в том числе и системы обеспечения информационной безопасности развиваются со стремительной скоростью. К сожалению те времена, когда один человек мог что-то сделать значимое остались в далеком прошлом, и настало время, когда результатов могут добиться только команды специалистов, а в некоторых случаях целые группы. Для достижения результатов нужно действовать максимально быстро, а в некоторых случаях даже быстрее быстрого. От появления уязвимости до её внедряния, от «детекта антивирусом» до внедрения крипта, от «абузы на домен/хост/серв» до развертывания на новом месте должно пройти минимум времени. Итак как же мы можем повысить производительность команды. Первое что мы можем предпринять, это использовать систему контроля версий, вот три наиболее популярные из них: 1) Git (http://ru.wikipedia.org/wiki/Git); 2) Subversion (http://ru.wikipedia.org/wiki/Subversion); 3) CVS (http://ru.wikipedia.org/wiki/CVS). CVS морально устарела уже, однако всё равно может быть использована. Я же рекомендую использовать Subversion или Git. Вот несколько потенциальных вариантов использования систем контроля версий: 1. совместная разработка; 2. развертывания системы; 3. крипт сервис. 3 Координация команды. Системы управления проектом. Как правило при реализации какого проекта на черном рынке, участники его не имеют личностных связей. Их устное общение, минимизировано из-за анонимности. Участники команды работают в разное время. Эти и другие факторы распределенной команды затрудняют процесс координации. Возникают ситуации не понимания приоритетов, многократное выполнение одинаковых задач разными исполнителями, недоработки связанные с потерей информации о той или иной задаче. Эффективность электронных сообщений критически низка. Для решения такого рода проблем на помощь нам могут прийти системы управления проектами. Основная их цель распределить задачи между исполнителями, получить оценку по времени на выполнение задач, непрерывный контроль над исполнением задач. Пример, таких систем – это Microsoft Project, Atlassian Jira, Redmine. Данные системы управления проектами могут адаптироваться практически под любые бизнес процессы от решения задач разработки ПО, поддержки клиентов, так и отслеживания какой-то операции, в которой задействовано несколько исполнителей. 4 Проблема грузовика. Документирование проекта. Представьте, что человека, отвечающего за разработку какого-то модуля или быть может даже целого продукта, сбивает грузовик. Ваши действия? … Ситуация не из приятных, но выход из неё один, если человек оставил, какие-то материалы сажать за них специалиста, который может попытаться разобраться, а если таковых нет, то начинать всё с начала. Данная проблема может быть рассмотрена не только в рамках разработки ПО, но и в других областях, где есть зависимость от группы лиц, которые могут внезапно пропасть. Как же оградить себя от подобных ситуаций? Второе над чем следует задуматься команде, это организация документирования их действий, принятие ключевых решений, сохранение необходимых конфигураций, моделей, бизнес-планов, баз и так далее. Другими словами организация документирования ключевых моментов. Наилучшим образом, для этих целей подходят wiki-системы, например Atlassian Confluence. Многие видели, что продаются исходные коды программ, но за частую эти исходные коды без документации не представляю практическую ценность, за неимением автора разобраться в них занимает достаточно большое количество времени. Напротив, если команда продает проект с исходным кодом, то приходится оказывать постоянные консультации, когда всего лишь можно было бы предоставить доступ к документации, которая собралась бы автоматом при создании проекта. Некоторые потенциальные способы использования wiki-систем документирования: 1. ведение документации по разработке ПО; 2. ведение документации по деятельности; 3. база уязвимостей. 5 Поддержка и общение с клиентами. Кто-нибудь задумывался когда-нибудь, почему крупные компании в большинстве своём просят оставить электронную заявку на свою проблему, сделать электронный заказ и другие способы получить от Вас информацию в электронном виде. Все эти действия направлены на повышение производительности и качества. Текущая ситуация на черном рынке в плане поддержки и общения с клиентами в корне не соответствует требованиям. В абсолютном большинстве случаев общением с клиентами занимается исполнитель, а крупные сервисы могут позволить себе менеджеров по обработке клиентов, но зачастую менеджеры – это дешевая рабочая сила в лице студентов или школьников. Они не обладают должными знаниями, а иногда и даже безответственны в силу невозможности иметь средств контроля над ними. Что же можно предпринять? Это организация электронной обработки заявок. Общение нужно сводить к минимуму, никаких задушевных бесед. Никаких переспрашиваний, постоянных отвлеканий, а есть ли решение той или иной проблемы, есть ли в наличие товар, возможно ли осуществить услугу. Общение только в случае возникновения ошибок в деятельности «системы поддержки», всё остальное по принципу: 1) заявка от клиента c указание деталей; 2) клиенту выдается номер заявки, по которому он может отслеживать её исполнение; 3) клиенту выдается максимальный срок исполнения его заявки; 4) клиенту выдается ответы (решение, товар) не позднее максимального срока; 5) если невозможно уложиться в срок, клиент предупреждается заранее. В интернете полно готовых решений по организации такой системы, но даже без использований их можно обойтись банальной формой обратной связи, написаной на PHP / ASP / PERL и другие. На практике, применял связку из Atlassian Jira + Confluence, приблизительный вариант настройки и как это работает можно посмотреть по этой ссылке. http://habrahabr.ru/post/125622/ 6 Непрерывная разработка (Continuos Integration / CI ). http://en.wikipedia.org/wiki/Continuous_integration Цитата из wiki: Непрерывная интеграция (англ.*Continuous Integration)*— это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий. В рамках нежестких (постоянно меняющихся) внешних бизнес требований и ограниченности во времени на стадию интеграции, за частую программное обеспечение поставляется заказчикам в непроверенном виде. В погоне за скорейшем внедрением нового функционала например эксплуатация уязвимости нулевого дня, нарушается работоспособность совершенного другого функционала. Выявление ошибок происходит путем ручного тестирования, и в некоторых случаях даже не может быть воспроизведено. Для решения этих проблем может как раз помочь практика непрерывной интеграции, работа ведется в следующей последовательности: 1. заказчик выдает требования; 2. ставится задача исполнителю; 3. после выполнения задачи; 4. билд машина осуществляет сборку; 5. затем тестирование; 6. если на этапе тестирование возникают ошибки; 7. формируются задачи, которые ставятся разработчикам; 8. если тестирование успешно; 9. происходит автоматическое обновление документации; 10. далее задача закрывается и заказчик информируется. Несколько примеров нетрадиционного использования CI методики: 1) Крипт сервис, сервис антивирусных проверок. Заказчик добавляет файл на проверку. Билд машина регулярно на агентах проверяет файл, если файл детектируется, автоматически ставится задача криптовщику, тот после исполнения закрывает задачу, заказчик уведомляется о рекрипте детектируемого файла. 2) Действия на основании логов, приходит лог с необходимой информации, автоматически задача проверяющему, он уже передает на других исполнителей по различным направлениям. 7 Итоги Крупные компании в плане поддержки клиентов и управления персоналом шагнули далеко вперёд. Разработанные ими технологии и методики можно использовать и в иных целях, что может позволит услуги на черном рынке вывести на новый уровень. Изложенный материал будет полезен также тем, кто собирается легализоваться, при организации предприятия, бизнеса. Автор не несет ответственность за ущерб, нанесенный с применением предоставленной информации. Данный материал только для ознакомления, и не является инструкцией по координации ОПГ.
