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

Ключевой проблемой любой организации являются изменения.

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

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

Если у вас проблемы с продажами, вам нужны изменения. Очевидно? Вроде да. Или продукты продаете не те, что нужны рынку, или их слишком мало, или слишком много, или сроки срываете, или качество — недопустимо низкое, или продавцы хамят клиентам – неважно, это причины. Чтобы эти причины перестали оказывать влияние на систему продаж, нужны изменения.

Если у вас проблемы со снабжением, то вам нужны изменения. Очевидно? Вроде да. Или поставщиков других надо найти, или заказы формировать почаще, или, возможно, пореже, или партии уменьшить, или логистику улучшить, или перестать наемным транспортом пользоваться, или начать наемным транспортом пользоваться. Не так важно, что именно надо изменить, но что-то изменить — надо.

Если у вас проблемы с автоматизацией, то вам нужны изменения. Очевидно? Вроде да. Или платформу сменить, или программный продукт другой взять, или программистов нанять, или программистов разогнать, или порядочного аутсорсера найти (ха-ха), или перестать пользоваться колхозным интегратором и нанять федерального, или послать федералов и найти в своей деревне увлеченного фаната, или пересмотреть управление ИТ-отделом, или изменить мотивацию программистов. Не важно, что именно, но что-то надо менять.Читать полностью »

Давным-давно в одной далёкой-далёкой... проекте, понадобилось мне сделать обработку http-запросов на Netty. К сожалению, стандартных удобных механизмов для маппинга http-запросов в Netty не нашлось (да и этот фреймвёрк совсем не для того), поэтому, было решено реализовать собственный механизм.

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

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3
Лекция 18: «Частный просмотр интернета» Часть 1 / Часть 2 / Часть 3
Лекция 19: «Анонимные сети» Часть 1 / Часть 2 / Часть 3
Лекция 20: «Безопасность мобильных телефонов» Часть 1 / Часть 2 / Часть 3
Лекция 21: «Отслеживание данных» Часть 1 / Часть 2 / Часть 3Читать полностью »

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3
Лекция 18: «Частный просмотр интернета» Часть 1 / Часть 2 / Часть 3
Лекция 19: «Анонимные сети» Часть 1 / Часть 2 / Часть 3
Лекция 20: «Безопасность мобильных телефонов» Часть 1 / Часть 2 / Часть 3
Лекция 21: «Отслеживание данных» Часть 1 / Часть 2 / Часть 3Читать полностью »

image

Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса иили его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.

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

Чего воду в ступе толочь, вступления писать, сразу к делу.

Первый слой – кто хочет?

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

Но до реальных изменений дело доходит крайне – крайне редко. Это, наверное, даже не единицы процентов, а доли одного процента. Почему так?

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

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

Воронка изменений - 1

Ой, не то. Вот так:

Воронка изменений - 2

Попробуем разобраться — кто, где отвалился и почему.

Итак, первый, самый широкий слой воронки – те, кто поднял руку.Читать полностью »

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

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

Как поделить архитектуру и реализацию и не поругаться - 1

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

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

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

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

Определение — понятно, но для управления качеством этого недостаточно. Это какая-то базовая, фундаментальная ценность, цель системы, а не руководство к действию. Что делать-то надо?

На что направить свои усилия, чтобы повысить качество? И качество чего надо повысить? Все слышали, что есть качество продукта, а есть – качество процесса. В чем разница? Что важнее?

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

Это что такое получится? Управление качеством? В конечном итоге – да, но путь немного странный. Мы не качеством управлять будем, а требованиями. Есть вроде такая область знаний – управление требованиями? В ИТ, в частности. Хотя, если посмотреть телевизор, там только и занимаются, что управлением требованиями – кажется, это «пропагандой» называется.

Попробую рассказать то, что я успел узнать за свою жизнь про «нормальное» управление качеством.Читать полностью »

Когда собирали доклады на голосование для участия в одной специализированной конференции, я хотел рассказать такую тему – как подсидеть директора по качеству. Это был бы конъюнктурный доклад про карьерный рост для программиста или ИТ-директора.

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

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

Я не знаю ни одной другой отрасли знаний, в которой трудилось бы такое же количество людей, ничего не понимающих в своей профессии. Это не шутка, не гипербола. Я наблюдаю за этими ребятами больше 15 лет — еще с тех пор, когда сертификат ISO еще был престижной редкостью. Я работал с директорами по качеству и специалистами, консультантами и аудиторами, преподавателями ВУЗов и президентами ассоциаций, студентами и аспирантами. Сколько из них, по-вашему, знают и понимают, что такое управление качеством и как его осуществлять? А, вы же знаете, я выше написал – ноль. Ладно, пусть будет 1 % — наверняка где-то, случайно, или волею небес, есть люди, которые что-то понимают. Ну и вы, если внимательно и без предубеждения отнесетесь к управлению качеством, тоже будете понимать. Так, может, и до 2% дотянем.Читать полностью »

Кто такие руководители, и зачем они нужны? Какая от них в жизни польза? Чем они вообще занимаются? А чем они должны заниматься?

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

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

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

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

Я использую специальную модель для оценки руководителей, с которой вам и предлагаю ознакомиться.Читать полностью »


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