IT-стандарты *

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

Для справки, я начал работать с компьютерами в начале 2000-х годов в России. Русский язык использует алфавит на основе кириллицы. И что касается языков, отличных от ASCII, все относительно просто: 33 буквы, у каждой есть варианты в верхнем и нижнем регистре, и преобразование верхнего/нижнего регистра обратимо. Так как букв всего 33, вы можете уместить их в 8-битной кодировке. Кроме того, есть еще место для псевдографики.

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

Одна из причин - сложная история Советского Союза и вычислительной техники - он был ​​изолирован от остального мира, и все организации, производящие компьютерное оборудование и программное обеспечение, принадлежали государству, поэтому оно могло навязать им стандарты. После распада СССР рынок был быстро захвачен западным оборудованием и программным обеспечением потому что советскую технику уже никто не производил. Частные софтверные компании тоже сразу начали выпускать ПО для импортных ОС - сначала это был DOS.

Старые советские системы в основном использовали кодировку KOI8-R. KOI расшифровывается как «Код Обмена Информацией», 8 означает 8-битный, а R означает русский (есть еще украинская версия под названием KOI8-U, украинский алфавит отличается от русского). Эта кодировка, мягко говоря, безумна: она была спроектирована так, что удаление 8-го бита оставляет вам несколько читабельную ASCII-транслитерацию русского алфавита, поэтому русские буквы не идут в обычном порядке.

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

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

Основными из них являются Европейский General Data Protection Regulation (GDPR) и, принятый в Калифорнии, California Consumer Privacy Act (CCPA). Сегодня подробно разберёмся, что это за законы, чего требуют и как внедрить их поддержку в свой сервис, сайт или мобильное приложение.

Это первая статья из цикла про приватность на iOS, где поговорим не только про законы, но и про изменения в политике App Store, AppTracking Transparency и IDFA.

Chief Technical Officer — представитель топ-менеджмента компании (помимо английской аббревиатуры, можно встретить название «технический директор»), который определяет технологическую стратегию компании и отвечает за внедрение новых технологий — все ради достижения финансовых и стратегических целей бизнеса.

Wi-Fi Alliance и IEEE разрабатывают несколько стандартов — в том числе кандидата на звание Wi-Fi 7. Поговорим об их особенностях — геолокации в помещениях и координированном обмене данными с несколькими точками доступа.

На настоящий момент (август 2021 года) автором данного перевода не было найдено хоть сколько-нибудь приемлемого перевода стандарта протокола TLS версии 1.2 на русский язык. Единственный найденный перевод находится сайте protocols.ru и, во-первых, доступен только в кэше поисковика, а во-вторых, при всем уважению к его переводчику, не устраивает автора по причине неудобочитаемости и трудности восприятия. И хотя на сайте efim360.ru находится качественно выполненный перевод стандарта протокола TLS версии 1.3, многие места этого перевода могут вызвать некоторые трудности для понимания, особенно у начинающего изучать криптографию читателя. Для устранения таких «белых пятен»   и было задумано осуществить перевод стандарта протокола TLS версии 1.2 на русский язык.     

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

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

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

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

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

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

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

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

Все понимают, что shit happens — и чаще всего не если, а когда. У нас может быть много девяток в SLA, но 100% ни у кого нигде никогда не бывает. Поэтому, когда этот SHIT все-таки HAPPENS, есть два пути. 

Путь первый — проблему можно скрыть, сделав выводы для себя. Под ковер замели — никто ничего не заметил. А тому, кто заметил, сказать: «Да вам показалось, все нормально!» Можно пойти по второму пути: не врать и не бояться. Для этого, конечно, нужна уверенность в себе и своей компетенции. Тогда мы спокойно тушим пожар, а не прикрываем пятую точку (может, даже не свою). 

Я — за второй путь. На конференции HighLoad++ Весна 2021 я рассказал, что можно сделать уже сейчас, чтобы спасение прода прошло максимально безболезненно и почему доверие пользователей — это важно. Видео выступления можно посмотреть здесь, а под катом вы найдете, как заранее подготовиться к инцидентам.

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

Я расскажу про причину зачем вам лично может быть полезно ревью кода сокомандников.

Казалось бы простая задача - развернуть Kubernetes кластер и в нем запустить централизованный мониторинг TICK стек и логирование ELK стек. Но для меня она осложнилась тем, что с этим технологиями я столкнулся впервые. Чтобы понять, как все работает, хотел пройти простые Quick Start инструкции. К своему удивлению, не нашел детальных актуальных описаний - либо отдельные статьи со своей спецификой, либо многостраничные книги по Kubernetes. Пока собирал пазл из многочисленных материалов, решил написать статью, в которой рассмотреть общую концепцию развертывания TICK и ELK стеков в Kubernetes. 

Для чего, вообще, решать задачу централизованного мониторинга и логирования в Kubernetes? 

Почему я продолжаю ездить на устаревших Москвиче и А-76? Этот вопрос мне часто задают мои соотечественники, соседи по даче и здесь на Хабре. Решил ответить сразу всем в этой заметке.

Что такое Core Web Vitals? Это набор определенных моментов и факторов, в совокупности действительно имеющих значительное влияние на ранжирование.

На самом деле, Core Web Vitals уже работает на протяжении какого-то времени. Ни много ни мало, с 2018 года. Помимо прочего, существуют официальные подтверждения в документации корпорации.

В Core Web Vital грядут изменения, способные изменить понимание о том, как стоит относиться, обсуждать и объяснять работу Core Web Vitals.

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

Привет, хабр! Меня зовут Полина. Я несколько лет занималась настройкой и развитием инцидент-менеджмента для eLama.

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

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

Мы в Dropbox считаем, что управление инцидентами — это центральный элемент нашей системы по обеспечению надёжности. И хотя мы также используем проактивные методы, такие как хаос-инжиниринг (сhaos engineering), то, как мы реагируем на инциденты существенное влияет на опыт наших пользователей. Во время потенциального сбоя сайта или проблемы с продуктом на счету каждая минута.

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

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

DaaS-сервис (Desktop as a Service) объединяет устройства Dell и современные сервисы Microsoft в единую подписку и обеспечивает бизнес технологиями для эффективной и безопасной работы сотрудников.