Задача: в Техническом Задании на комплексную IT-систему был пункт – «выполнить расчет коэффициента готовности системы».
Решение: использовать материалы из ГОСТ, запросить дополнительные данные у вендоров по элементам оборудования и использовать несложную математику для выполнения итогового расчета.
Читать полностью »
Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.
Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2Читать полностью »
Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.
Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2Читать полностью »
Есть много обстоятельств, которые могут быть катализаторами создания плохого ПО: используемые инструменты, качество коммуникаций в команде, персональные качества разработчиков, методологии и т.д. И есть среди них одна вещь, которая является корнем почти всех остальных: воображаемые проблемы.
Большинство сложного или забагованого программного обеспечения не планировалось быть сложным и, уж тем более, забагованым. Оно просто было создано для выполнения не тех задач, которые лежали в основе первоначального замысла.
Давайте представим себе, что вы записываете популярный подкаст и в какой-то момент задумались о создании собственного сайта — ну, знаете, с информацией о вашем подкасте, записями прошлых выпусков, статьями, ну и возможно, кое-какой рекламой. В самом деле, ну сколько можно делиться прибылью с какими-то там посторонними издателями?
И вот вы решаете нанять людей, которые сделают для вас этот сайт. Вы пишете для них абсолютно чёткие требования:
Вы даёте эти требования разработчикам и, возможно, немного общаетесь с ними. Проходит 2 месяца. Они показывают вам демо и вы покрываетесь красными пятнами. Становится понятно, что вы только что выбросили в пропасть 15 000 $. То, что вам показали, совершенно неприемлемо ни с какой стороны, просто куча мусора. Вы хотите назад свои деньги, но поезд уже ушел.
Привет! Адресую эту статью себе более молодому и неопытному, а также всем, кто чувствует неуверенность в подходе к технической документации. Хотя если кому-то из зубров проектного дела она поможет, буду рад вдвойне.
Для составления ТЗ существует множество стандартов и спецификаций, но если молодые студии при разработке простенького интернет-магазина будут пытаться им соответствовать, то не успеют реализовать и пары проектов, как разорятся, закопавшись в кучу непонятных документов.
По результатам проведения многочисленных эксплуатационных оценок ЦОДов по всему миру Uptime Institute отметил, что штатная укомплектованность персонала в дата-центрах сильно варьируется от места к месту. Это наблюдение несколько озадачивает, но это неудивительно. Хотя кадровое наполнение является важным аспектом деятельности для центров обработки данных, которые пытаются сохранить эксплуатационное превосходство, множество других факторов влияют на решение организаций о требуемом уровне укомплектования персоналом.
Среди факторов, которые могут повлиять на общую штатную численность можно выделить сложность центра обработки данных, текучесть кадров, количество требуемых рабочих часов техподдержки, количество контрактов с подрядчиками и бизнес-цели обеспечения доступности. Расходы также вызывают беспокойство, поскольку каждый сотрудник является для ЦОДа прямыми затратами. Из-за этих многочисленных факторов необходимо постоянно пересматривать уровень укомплектованности центров обработки данных персоналом, чтобы обеспечить эффективную поддержку по разумной цене.
Uptime Institute часто получают вопрос: «Каков надлежащий уровень укомплектованности персонала для моего ЦОДа?». К сожалению, нет лаконичного ответа, который был бы универсален для каждого дата-центра. Надлежащее кадровое обеспечение зависит от ряда переменных.Читать полностью »
Как видно из новостей, облака и крупные компании — это удобно и надёжно, но далеко не всегда:
Так что, кормить облачные сервисы хорошо, но в некоторых случаях "своя рубашка ближе к телу".
Изначально, одной из моих целей являлось исследование построения собственной системы, в частности NAS с возможностью работы "домашним сервером".
Постепенно возникла идея, что в свете недавних событий, информация такого плана интересна, и неплохо бы аккумулировать её в одном месте, структурировать и дополнить.
В итоге, должно сформироваться что-то вроде общедоступных best practices для энтузиастов, начиная от выбора и сборки железа и заканчивая программным обеспечением.
Данная статья является оглавлением к статьям по построению NAS.
Допустим, аппаратная часть NAS собрана и на неё установлена ОС, например, как показано здесь. И сейчас у вас есть работающий сервер с Debian, который загружается, подключен в сеть, и вы имеете к нему полный физический доступ.
Теперь надо спроектировать среду, позволяющую легко и безопасно добавлять, удалять прикладные сервисы, а также управлять их работой.
Золото досталось России, серебро разделила Россия и Италия, бронза досталась Украине. Таковы результаты европейского финала престижного соревнования InnovateFPGA под эгидой Интела. Победители поедут в Калифорнию, где встретятся с финалистами из Америки и Азии. Надеюсь, теперь не нужно будет объяснять на Хабре, почему Verilog и ПЛИС/FPGA стратегически важны, несмотря на то, что «вакансий на джаву больше».
Студенты, которые сейчас делают проекты на ПЛИСах, через несколько лет будут делать массовые микросхемы для самоуправляемых автомобилей, ускорителей нейронных сетей, дополненной реальности и других приложений, в который обычный процессор не справляется. Именно поэтому Intel потратил 16.7 миллиардов долларов на покупку Altera и вход в рынок ПЛИС. А на днях Интел купил еще и компанию eASIC для дешевой конверсии дизайнов из ПЛИС в ASIC (в eASIC есть достаточно многочисленная российская команда).
Победа российских и украинских команд в интеловском конкурсе InnovateFPGA возникла не на пустом месте, а в результате работы конкретных людей в ЛЭТИ, ИТМО, КПИ и других местах, о которых уже были статьи на Хабре. Если продолжить эти начинания и расширить преподавание ПЛИС и языков описания аппаратуры во все технические вузы от Калининграда до Якутии, от Львова до Тбилиси и Астаны — то через пару десятилетий это может изменить расстановку сил в мировой электронной промышленности примерно так же, как работы Курчатова и Королева изменили расстановку сил в мировой атомной промышленности и освоении космоса.
Когда только Dropbox запустился, один пользователь на Hacker News прокомментировал, что реализовать его можно несколькими bash-скриптами с помощью FTP и Git. Сейчас такого сказать никак нельзя, это крупное облачное файловое хранилище с миллиардами новых файлов каждый день, которые не просто как-то хранятся в базе данных, а так, что любую базу можно восстановить на любую точку в течение последних шесть дней.
Под катом расшифровка доклада Славы Бахмутова (m0sth8) на Highload++ 2017, о том, как развивались базы данных в Dropbox и как они устроены сейчас.
О спикере: Слава Бахмутов — site reliability engineer в команде Dropbox, очень любит Go и иногда появляется в подкасте golangshow.com.
