Рубрика «Анализ и проектирование систем» - 65

Когда только Dropbox запустился, один пользователь на Hacker News прокомментировал, что реализовать его можно несколькими bash-скриптами с помощью FTP и Git. Сейчас такого сказать никак нельзя, это крупное облачное файловое хранилище с миллиардами новых файлов каждый день, которые не просто как-то хранятся в базе данных, а так, что любую базу можно восстановить на любую точку в течение последних шесть дней.

Под катом расшифровка доклада Славы Бахмутова (m0sth8) на Highload++ 2017, о том, как развивались базы данных в Dropbox и как они устроены сейчас.

О спикере: Слава Бахмутов — site reliability engineer в команде Dropbox, очень любит Go и иногда появляется в подкасте golangshow.com.

Содержание

Развитие баз данных в Dropbox. Путь от одной глобальной базы MySQL к тысячам серверов - 1
Читать полностью »

Знакомьтесь, авторы июльской статьи для «Календаря тестировщика» Андрей Марченко и Марина Третьякова, тестировщики-аналитики Контура. В этом месяце ребята расскажут о моделях рабочего процесса по тестированию аналитики, и как они начали тестировать аналитику до стадии разработки. Опыт ребят будет полезен менеджерам, тестировщикам и аналитикам некрупных продуктовых команд, которые не живут в рамках стартапа и для которых качество важнее скорости.

«Календарь тестировщика» за июль. Тестирование аналитики - 1

Модели рабочего процесса по тестированию аналитики

Модель 1

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

Минусы:

  • дефекты в аналитике не будут выявлены раньше стадии тестирования,
  • есть риск того, что задача из тестирования отправится снова в аналитику на доработку. Как следствие TimeToMarket задачи существенно увеличивается.

Ошибки аналитики, выявленные при тестировании, стоят дорого или очень дорого.

Плюсы:

  • сокращается время тестировщика для задач, где не требуется аналитик (инфраструктурные, рефакторинг).

Модель 2

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

Читать полностью »

Опыт создания клиент-серверного приложения для автоматизации регистрации доменных имен на сайте хостинг провайдера.

Часть первая: структура проекта.

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

Я ознакомился с сайтом и обнаружил там много JavaScript и было принято решение использовать симуляцию пользовательской активности на сайте с помощью таких инструментов, как Сhromium и Lazarus-IDE на стороне сервера, с установленным там Linux Debian.

Я приступил к тестированию своего решения.

imageЧитать полностью »

Если вы не живете в пещере, вы, возможно, знаете, что микросервисы – это архитектура сегодняшнего дня. С развитием этого тренда, в продукте Segment на раннем этапе приняли его, как лучшую практику, которая служила хорошо в одних случаях, и, как вы скоро увидите, не так хорошо в других.

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

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

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

Как всегда без имен и названий, и так как я дополнительно связан подписью о неразглашении, еще и с немного видоизменённой историей (и опуская некоторые подробности, на публикацию которых я не получил разрешения).
Ниже следует реальная история проникновения на компьютер сотрудника… ну скажем некоторого частного банка. События, о которых повествует ваш покорный слуга, происходили в некоторой европейской стране не так что бы давно, еще до DSGVO (GDPR, RGPD) но в процессе становления оного, в преддверии так сказать.

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

Опустим слова, которые пришлось выслушать от краснеющих на глазах IT-безопасников, но общий лирический посыл таков — я бросаюсь голословными обвинениями, а у них — всё на замке, а ключ у CSO в кармане под сердцем.
Попытки объяснить, что система безопасности выстроенная вокруг firewall+proxy+webwasher like content-filter & antivirus, без какой-либо худо-бедно настроенной гибридной IDS (HIDS+APIDS), хонепотов и т.д. и т.п., во первых по определению не является безопасной, во вторых я же как бы показал уже несколько мест, где оно как минимум не комильфо. Попытки вернуться к конструктивному диалогу (собственно обратно к разбору) разбивались о трехэтажную стену обиды, выстроенную всем отделом.

Свернув совещание и отпустив сотрудников, CSO в купе с двумя важными начальниками попытался всё-таки честно выяснить у меня где собака порылась и понять как дальше жить как собственно и что конкретно, по моему скромному мнению, нужно делать.

Читать полностью »

Моделирование физических процессов при разработке электроники: почему и для чего? - 1

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

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

Почему именно больница?

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

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

Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы - 1

Программный код внутри (но этого никто не видит)

При чем тут больница, если мы разрабатываем ПО?

А вот и нет, дорогие разработчики, руководители, аналитики, тестировщики.

Не программное обеспечение вы разрабатываете… Возьмем Android, — это ПО. А если, например, перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.
Читать полностью »

PlantUML — все, что нужно бизнес-аналитику для создания диаграмм в программной документации - 1

Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Читать полностью »

Почему опоздать на авиарейс и не полететь — это не всегда плохо? Кто виноват в том, что вы опоздали на стыковку? Зачем приезжать в аэропорт заранее? Может ли полететь А380 в Астрахань? Почему интуиция не всегда работает? Неожиданности случаются — никогда не было и вот опять? Почему пассажиры хлопают пилоту после посадки?

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

Представили? Так вот, именно таким проектом в настоящий момент является проект ГИС ЖКХ, о котором ранее мы начали рассказывать и теперь хотим продолжить.

Управление релизами на ГИС ЖКХ — делимся опытом и боремся с интуицией - 1

Источник
Читать полностью »

Автор: Adam Alami, PhD Fellow, IT University of Copenhagen (перевод с англ.)

ВВЕДЕНИЕ

Нефункциональные требования широко представлены в литературе. Нет недостатка в определениях и примерах нефункциональных требований. Международный институт бизнес-анализа (IIBA) определяет нефункциональные требования следующим образом:

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

Ключевыми словами в этом определении являются «не имеют прямого отношения к поведению или функциональности решения». Это либо «условия», либо «качества».

Условия: они являются внешними или внутренними ограничениями. Внутренние ограничения — это политика и саморегулирование организации, в то время как внешние ограничения — это государственные правила, отраслевые стандараты и другие параметры, определяющие бизнес-среду.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js